Makumba Specification

OLDSTYLE features that are still accepted are presented in darkblue
(INTENDED features are presented in red with parentheses)

Content

• Data Definition Language... writing MDDs
  • Types, objects, databases
  • Fields
  • Default fields
  • Simple field types
    • int - real - char - text - date
  • Structural (relational) types
    • ptr - set
  • Macro types
  • Field attributes
  • Object title
  • Include mechanism
• OQL language ... getting data from the database
• Business Logic ... adding logic to basic operations
  • Attributes
  • Java Handler classes
  • Login, <mak:login>, <mak:logout/>
• Presentation and internal representation principles
• Presentation with JSP taglib ... viewing/editing data thru HTML pages
  • Makumba in Java Server Pages
    • Makumba Controller
    • JSP tag parameters
  • <mak:list>
    • <mak:object>
    • Attributes and OQL in <mak:list > and <mak:object >
    • <mak:value/>
    • mak:count(), mak:maxCount(), mak:lastCount()
    • <mak:if>
    • <mak:attribute>
  • Forms
    • <mak:newForm>
    • <mak:addForm>
    • <mak:editForm>
    • <mak:form>
    • <mak:input/>
    • <mak:action/>
  • <mak:deleteLink/>
  • <mak:response/>

Data Definition Language

Types, objects, databases

Data definitions describe data types (or classes). They are placed in files contained in directory hierarchies, and the directory name is part of the type name (similar to Java packages). For example the file best/Student.mdd describes the type best.Student. Type names can contain letters, digits, underscores and dashes and cannot contain slashes and dots. Usually, the directories are used to separate organisations and projects.

Data objects (records) are stored in databases.

The actual implementation of the database is not part of this specification but implementation suggestions will be made. Data can be copied and/or replicated between different databases, even between different DB engine types.

Fields

Every data definition file contains field definitions, separated by newline.

A field definition looks like:

fieldname= [attributes] fieldtype [parameters] [; description]

(Automatic labeling: The field description might be used at interface levels to present that field. It is typically shown at the left of, or somewhere near to, the input control (text box, radio button, chooser, etc) that allows for data input in that field. If a field description is not present, its field name stands for its description by default.)

Comment lines can be inserted in the data definition files as follows:

# your comment...

Default fields

Every datatype has some additional fields by default, as follows:

• Primary Key field, consisting of two parts [DBSV with 8 bits | UID with 24 bits]:
  • Database identifier (DBSV). It is unique (within the webapp) per database. All objects created thru that webapp and in that database get the same value. It is set by property dbsv in the database config file.
  • Object identifier (UID): unique id for the object in the given database.
  
  This combination ensures that no two objects of one type have the same primary key field. See how to configure this.
  The name of the primary key field is the same with the last part of the type name. If another field by that name is defined by the makumba user, this field will be renamed in the database.
• Object creation time
  Can be accessed as TS_create.
• Last modification time. Updates whenever the object is changed. The initicial value is TS_create.
  Can be accessed as TS_modify.

Simple field types

int

A 32-bit integer. For example

shoeSize= int; Shoe size

If the int can have a limited number of values, it can be described as follows

gender= int{ "male"=0, "female"=1 }; Sex

This will help the presentation layer to present a suitable input control (e.g. male female )

real

A read number with double precision with (2-2^-52)·2¹⁰²³ as max value and 2^-1074 as min value. For example:

high= real; high of a person

char

A char field contains a number of characters. Maximal width must be specified and is limited to 255. (Optionally a minimal number of characters (lesser than max) can be indicated). Both must be positive integers. For example:

#fieldName= char[maxWidth]
name= unique char[80]; Username
#fieldName= char[minWidth..maxWidth]
password= encrypted char[6..10]; Secret password

"unique" and "encrypted" are field attributes, explained below.

DEPRECATED (use int{...} instead): If the char can have a limited number of value, it can be described as follows

gender= char{ "male", "female" }; Sex

This will help the presentation layer to present a suitable input control (e.g. a HTML SELECT)

text

An unlimited-length string of bytes or characters. This type was designed to accomodate large text or binary content. It is implemented with LONGVARBINARY or its counterparts, depending on the underlying DB engine.

application= text ; Application letter
description=text  ; Description of object
image= text	  ; Picture attachment

date

A date and/or time.

birthdate= date; Date of birth
arrivalTime= date; Arrival time

Structural (relational) types

Pointers (ptr)

Pointers define a reference to an object of a certain type. For example

citizenship= ptr general.Country; Citizenship

The type can be defined on-the-spot for a single usage. For example

addres= ptr ; Address
address->street= char[80]; Street
address->number= int; Number

address= ptr{
    street= char[80]; Street
    number= int; Number}; address

Sets (set, bag, list)

Sets define a number of references to multiple objects of a certain type. For example:

language= set general.Language; Spoken languages

This type accomodates sets, bags and lists. The set and list constraints (sets have to contain only one element of a certain value and lists have to be ordered) have to be cared for by the programmer. Lists are easy to represent, just having an integer field, for the order.

The type which the set is made of can be defined on the spot:

addresses= set; Addresses
  addresses->street= char[80]; Street
  addresses-> number= int; Number

addresses: set{
    street: char[80]; Street
    number: int; Number }; Addresses

The set can contain enumerated int values :

place= set int {"home"=1, "away"=0} ; Home or away

DEPRECATED: The set can contain enumerated char values :

place= set char {"home", "away"} ; Home or away

Macro types

A name can be defined for a more complex type and it can be reused in the file. This can be done with a !type directive

!type.yesno= int{"yes"=1, "no"=0}
!type.rank= int{"neutral"=0, "very good"=5, "very bad"=-5}
married=yesno
happyInLife=rank

Field attributes

• fixed fields can only set during the record's insertion in the database. The subsequent updates will not update the field
• not null fields will produce a exception if an attempt is made to insert/update without them being initialized
• unique fields have a unique value in the respective object, for the respective type
• (encrypted fields are encrypted when written to the database and decrypted when read)

Object title

One of the fields is always the object title, and is normally presented differently from other fields in user interface. This is the field called "name" if that exists, otherwise it is the first non-pointer field in the record description. If another field needs to be title, it can be specified like

!title=gender

address->!title= street

Include mechanism

A record description can include text from one or more files. This is declared as

!include=name_of_included_type

The included file has the idd extension and is found in a similar way like the data definitions.

The included file is inserted instead of the !include line. There can be more include lines in a record description file. If a field is defined that exists also in the included metadata, the defined field takes precedence. If

fieldname=

it means that it does not actually exist. this can be used to cancel an included field.

OQL language

The database can be interrogated using the following language ( [] means optional, {} means any number of repetitions). OQL is similar to SQL, a specification can be found at http://www.odmg.org (or check this PDF). Makumba recognizes a subset of OQL at the moment, which it translates to the host SQL when necessary.

SELECT expression [[AS] label] {, expression [[AS] label] }
FROM {type [AS] label | label.field{.field} [AS] label }
[   WHERE expression
    [    GROUP BY expression {,expression}
        [  HAVING expression {,expression}  ]
    ]
]
[ORDER BY expression {,expression} [(ASC|DESC)] ]

Notations like label.field{.field} only allow "field" to be of pointer type in expression and set type in FROM. In expressions, also label.ptr{.ptr}.simplefield is valid.

If a label, representing a type, appears alone in an expression, a default field will be added. The default field depends on the type of the label:

• for set XXX types (sets of foreign objects), the label denotes the pointer to the set member
• for set int { } and set char { } types, the label denotes the set member (i.e. and int or a string)
• for all other types, the label denotes the pointer to that object

ms.account_active=1 OR ms.account_active=nil

Business Logic (BL)

Attributes

Java Server Pages use attributes to keep the state of the application. Makumba builds upon that its own notion of Attributes that keep the read-only state of a makumba task. They represent the "environment" of that makumba task. The typical example is a JSP page during execution, with its HTTP and session parameters as attributes. Since other kinds of attributes are possible, the attribute specification is kept HTTP-independent. Makumba BL code sees the attributes as an org.makumba.Attributes object.

Java handler classes

Java handler classes are classes that implement the "business logic" of the organisation. Every makumba page will look for a handler, and will call its methods when needed. Check also the <mak:newForm> to know which methods are called.

Handler Discovery

Each page will determine its handler class on first access, after being compiled. If the class changes on disk, a webapp reload is generally needed for the new class to take effect.

The handler is 'discovered' by decomposing the full path of the JSP page, and finding a class with a matching name. Decomposition breaks the full path at every capital letter, or forward slash. For example, with the page path /student/mycv/indexPersonal.jsp, the following criteria are applied, in order:

The class name prefix (e.g. java package name) can be regulated per parts of the site in a file called MakumbaController.properties which can be found in the CLASSPATH (just like MakumbaDatabase.properties). For example, the file can contain:

/student=org.eu.best
/makumba=org.makumba
/=test

There are good reasons to take into account the name of the response page of a form when looking for the business logic. Still, it is the name of the page that contains the form which matters. It is good practice for both pages to actually have the same handler class.

All methods of the handlers are http-independent. Methods are non-static, so the handler classes can use inheritance to their advantage. Still, handler classes are singletons (only one instance of a certain class in a JVM). For example, the validation of a form can be in a class that is closer to the actual JSP application (view level) while the more view-independent methods can be in the parent of that class. For example:

org.eu.best.minerva.StudentHandler extends org.eu.best.StudentHandler

Role of Java handlers

1. find attributes unknown by pages. e.g.

   <mak:object from="best.Student stud" where="stud=$student"> ...</mak:object>
   

   If the $student attribute is not known in the page (from a http argument) or in the session, the find{AttributeName}(Dictionary existingAttributes, Database d, String expression) method is called for the Handler object. In this case findStudent(). The handler has to compute the attribute, based on existing attributes, making DB accesses.

   The find{AttributeName} method's name is constructed literally from the name of the attribute (capitalising only the first letter), so dots and other illegal characters for java identifier names, are not to be used. Also, one shouldn't use 2 attribute names that differ only in the capitalisation of the first letter.

   For example "lbg.$lbg_order" (in an example elsewhere in the specs), will generate a call findLbg_order(otherAttributes, db) and the Java handler will return the default ordering for LBGs (say "name").

   If the attribute is computed successfully, it is associated with the session (i.e. set as JSP attribute in session scope)

   If not, an exception will be thrown (typically org.makumba.UnauthenticatedException), and the engine will act accordingly (i.e. ask for authentication).

2. execute action methods in response to makumba forms. See makumba forms and actions below.

3. ( later: return query parts, as methods. e.g. <mak:value expr="lbg.$title()" /> will generate a call to method BestInternalLbgTitle(lbg) which can return an OQL expression "concat(lbg.id, \"-\" lbg.name)" (such methods can be put directly in the Makumba data definitions) For now, OQL only accepts count() and sum(), but that can be easily fixed, till then, the method can be replaced by hand: <mak:value expr="lbg.id"/>-<mak:value expr="lbg.name"/> )

Handler Initialization

Whenever a handler is used in a new context (i.e. with a different set of attributes, e.g. a new page access), a method called checkAttributes(Attributes a, Database db) is looked for and executed, if it is defined.

checkAttributes can perform sanity checks for attributes used in the respective logic (in case of mismatches, org.makumba.UnauthorizedException is usually thrown), can load attributes that are absolutely needed for page execution (formerly given by the requiredAttributes() method), etc.

Login

If the attribute cannot be found due to wrong login information, org.makumba.UnauthenticatedException is usually thrown.

The principal (the person who logs in) can have more members (e.g. group, Lbg, Company representatives). E.g. the findCompany() method will check to see if the authentication (email_address and password) corresponds to any company representative of that company. If yes, it will return that company.

Login can be done in 2 ways:

1. (Http basic authentication login: will set the attributes $username, $password )
2. cookie login: done in a page called login.jsp, in the same directory or (if missing) in any of the parents. It should contain at least:

   <mak:login>
     <input type=text name=username>
     <input type=password name=password>
     <input type=submit>
   </mak:login>
   

   The login form will pass further (as hidden arguments) all the http parameters it got. Note that <mak:login> is only needed upon automatic login (a page displayed when the user requested another page, that needs authentication). If you wish to ask for login manually in a startup page, a normal HTML form is enough.

To cancel out a certain attribute, in order to produce a new login, the logout tag is available

<mak:logout actor="student"/>

You can remove (cancel-out, logout) multiple attributes from the session by using <mak:logout actor="attribute name"> several times and/or by using the star (*) wildcard, e.g.:

<mak:logout actor="demo_*"/> (attributes whose names start with "demo_")
<mak:logout actor="*app"/> (attributes whose names end with "app")
<mak:logout actor="*"/> (all attributes; this "invalidates" the session)

Presentation and internal representation summary

This table describes the data types and their default user interface representation. That user interface can be altered with the Presentation language described below. Orientative SQL and Java types are presented.

Presentation with JSP taglib

Makumba in Java Server Pages

Makumba tags are written according to Servlet 2.3 specification and JSP 1.1 specification. You will need a so-called "servlet container" that supports them both, such as Apache Tomcat. The corresponding WEB-INF/makumba.tld is already included in the distribution makumba.jar. The example WEB-INF/web.xml can be found in Makumba cvs repository (http://cvs.makumba.org/servlet_context/WEB-INF/).

Before using Makumba tags in your JSP pages you also need to declare the taglib with:

<%@ taglib uri="http://www.makumba.org/presentation" prefix="mak" %>

A few resources on JSPs (don't be afraid to try first, read later) :

• JSP documentation by Sun
• J2EE web services documentation by Sun. This is an introduction on the various technologies that you might use when building webapplications using Java2 (J2EE).
• Gentle introduction to JSPs

Makumba Controller

The makumba controller is a component running in the 'servlet container'. When a request for a makumba page enters the servlet container, the controller will intercept the request, and perform its "controller" activities (cfr. the model-view-controller pattern) :

• checking if the page has the appropriate attributes (see handler initialisation; e.g. force login).
• checking if the page request is the result of a form submit or a deleteLink. If so, perform the relevant actions in the handler and database.
• deal with problems (exceptions) during the controller activity:
  • if org.makumba.LogicException is thrown, the Exception can write a message to the <mak:response> in the requested page.
  • org.makumba.UnauthenticatedException and org.makumba.UnauthorizedException will force login (although UnauthorizedException probably shouldn't, bug 444)
  • if another exception occurs, an errorPage will be shown instead of the requested page.

For this to work, the correct configuration must be applied in WEB-INF/web.xml (example file). The following would tell the makumba controller to filter all requests for .jsp files.

  <filter>
     <filter-name>makumba_controller</filter-name>
     <filter-class>org.makumba.controller.http.ControllerFilter</filter-class>
  </filter>

  <filter-mapping>
    <filter-name>makumba_controller</filter-name>
    <url-pattern>*.jsp</url-pattern>
  </filter-mapping>

Note that if (in this example) the result page for a makumba form would be an .html page, then the makumba controller would not intercept the .html page request, and the actions implied by the form, would not be performed.

JSP tag parameters

JSP-tag parameter values are either FIXED or RTEXPR (runtime expression). A FIXED tag parameter must have a constant, literal value, while an RTEXPR can also be of the form <%= java_expression %>. On the other hand, some FIXED parameters can contain jsp attributes like $attr in makumba tags.

All parameters are optional unless specifically mentioned as being mandatory.

Specific concern can be the parameter quoting. Tag parameters can be written as name="value" or name='value' (note: the stringLiteral on DATE must be quoted with "). The choice of quote can be determined by the need to use either double or single quote as part of the value itself. If the quote is also present within the value, it must be escaped by a backslash.

  <mak:list from="general.Person p" where="p.gender=\"male\"" >
  <mak:list from="general.Person p" where='p.gender="male"' >
  <mak:list from="general.Person p" where="p.gender='male'" >
  <mak:list from="library.Book b" where="b.publisher=\"O'Reilly\" " >    
  <mak:list from="library.Book b" where='b.publisher="O\'Reilly" ' >

Quotes in extra HTML formatting parameters, such as styleClass, title, styleId, onClick ... need some special attention with quotes. The parameter values are copied verbatim (with no modifications by makumba) to the resulting HTML, always surrounded with double quotes ("). This means that you have to use other quotes, like single one ('),
If you need to pass a literal backslash (\) you have to escape it with a preceeding backslash (\\).

  <mak:input ... onClick="alert(this.value);"/>
  <mak:input ... onClick="alert('Hello world!');"/>
  <mak:input ... onClick="alert('Hello\\nWorld');"/>

Unfortunately the idea to use a sequence of escapes, eg writing \\\' in the JSP page to set the tag attribute to \', which could be handy for javascript tag attributes, is confusing the Tomcat servlet container.

<mak:list...>...</mak:list>

Performs a query on the database. The body of the list, if present, is run once for every item in the resulting data (size 0..N), e.g. to display it. Queries are generated on the spot and can be nested.

Example:

<mak:list from="best.Student s, s.person p" where="p.gender=\"male\""
          orderBy="p.name">

    <c:if test="${mak:count()}">
       <p> There are ${mak:maxCount()} male students:
    </c:if>

    <br> <%= counter %>.
    <mak:value expr="p.name"/>
    <mak:value expr="p.surname"/> <br>
    <mak:list from="p.addresses a">
       <mak:value expr="a.streetno"/> <mak:value expr="a.city"/>
    </mak:list>
</mak:list>

<c:if expr="${mak:lastCount()==0}"> There are no male students. </c:if>

<mak:object  ...>.... </mak:object>

Like list, but the query can only have zero or one result. A zero value for maxCountVar and countVar indicate that the object does not exist.

Example: See <mak:list>.

Attributes and OQL in <mak:list > and <mak:object >

Attributes are accessible through $AttributeName to any makumba tag. Typically they will be present in OQL sections instead of $number attributes (therefore the OQL sections of these tags is not "pure"). For example:

<mak:list from="best.internal.Lbg"
          where="lbg.country=$country"
          orderBy="lbg.$lbg_order">
  .....
</mak:list>

If a $ (dollar) sign needs to be in the string, the escape is $$.
If at the end of an attribute there has to be a Java identifier letter, the attribute name can be written as text1$attrName$text2, that is, with $ at both ends.

The http parameters are automatically set as page attributes. Other attributes can be set by the Java code as attributes in any scope (page, request, session, application) using pageContext.setAttribute(name, value, scope).

The query generator is setting all the attributes that are logically possible as prepared query parameters. For example, the $country above is a query parameter since it's a value, but the $lbg_order will not be accepted as query parameter, since it's a field name.

If an attribute has multiple values, it is expanded into multiple OQL parameters. For example:

<mak:list from="best.internal.Lbg" where="lbg.status in set($status)" >

<mak:value  .../>

Displays the value of an expression from within the query.

Example:

<mak:list from="best.Student s, s.person p"
	where="p.gender=\"male\"" orderBy="p.name">
    <mak:value expr="p.name"/>
    <mak:value expr="p.surname"/>
    <mak:value expr="p.birthdate" var="birth" printVar="printBirth"/>
    <% // we only print the birthdate if it's after some date
         if ( ((java.util.Date)birth).after(new java.util.Date(1980, 0, 1)) )
             out.print(printBirth);
    %>
    <mak:value expr="s.person.favoriteQuote" maxLength="60" addTitle="auto" />
</mak:list>

mak:count(), mak:maxCount(), mak:lastCount()

• mak:count() gives the number of the current iteration inside a mak:list. it has no value outside the list
• mak:maxCount() gives the total number of iterations inside a mak:list. it has no value outside the list
• mak:lastCount() gives the total number of iterations of the previous mak:list. it has no value inside the list

<mak:list ...>
   <c:if test="${mak:count()==1}">These are the list elements: </c:if>
   <tr bgcolor="${mak:count()%2==1?"white":"grey"}">
       <td>this shows in alternative colors</td>
   ...
   <c:if test="${mak:count()!=mak:maxCount()}">
       a separator where we can have any <b>tag</b> 
       we don't want separators to be shown after the last element 
   </c:if>
</mak:list>
<c:if test="${mak:lastCount()==0}">These are no elements </c:if>

<mak:if  ...> ... </mak:if>

Displays the body of the tag only if the OQL expression evaluates to true.

Example :

<mak:list from="best.Student s"
	  where="s.person.birthdate <> nil" orderBy="s.name">
   <mak:value expr="s.person.name"/>
   <mak:if test="s.person.hideAge = 0">
      was born on <mak:value expr="s.person.birthdate" />
   </mak:if>
</mak:list>

<mak:attribute  .../>

Displays the value of an attribute, or sets it to a Java variable.

Example:

<mak:attribute name="pattern" var="pattern" exceptionVar="exception"/>

<% if (exception!==null) {
     pageContext.setAttribute("pattern", (String)pattern+"%");
%>
   <mak:list from="type t" where="t.field like $pattern" >...</mak:list>

<% } else { %>
   No pattern argument. Please indicate one.
<% } %>

Forms

Makumba can produce four types of forms: new, add, edit and generic forms.

All forms have a number of common features: They can include <mak:input > tags. They all can have "action", "method", "handler", "name" and "message" arguments.

Handler methods (if they exist) are executed by the makumba controller, when the form is submitted to another makumba page.

Non-generic (type specific) forms
New, edit and add forms are type specific. Their fields must be named after the fields in the respective type (and related fields).

If there is a business logic class, the engine will look (once after each page compilation) for the corresponding handler method. The handler methods are executed before the default action and may prevent the action from being executed by throwing an exception. Some forms also have an after-action handler method.

If the handler class exists but no handler method can be found, an error is thrown (the site is not allowed to do the operation, e.g. StudentHandler will never have a on_newLibraryBook() method). If the handler class wishes to allow the action, it can define an empty handler method.

Multiple forms
- addForms can add to the subsets of object produced by the enclosing newForm.
- any number of levels of form inclusion is possible but only the outermost form can have an action, onSubmit, and method and other attributes specific to HTML forms.
- all form actions take place in a single transaction, which is rolled back by the controller filter if there is an error.
- after_ methods are not executed in correct order (bug 689)

<mak:form action="blabla">
<%-- the topmost form, will result in a HTML form, may or may not have logic, 
     or it can be a specialized form (new, edit, add...)
--%>

  <mak:input name="first" /> <%-- the topmost form can have fields of its own --%>

<mak:list .... > 
  <mak:addForm object="bla" field="bla" >
  <%-- note that there is no action indicated here, it's the action of the 
       topmost form a normal on_add BL method will be called 
   --%>
     <mak:input name="second" /><%-- the topmost form can have fields of its own, 
                                     even repeated in loops 
                                --%>
     ...
  </mak:addForm>
</mak:list>

<mak:list .... > <%-- there can be more than one loop in a root form -- %>
...
</mak:list>
<input type=submit> <%-- it's easy to add a submit button anywhere --%>
</mak:form>

(Later, new and edit forms that have no body, will build default forms. )

<mak:newForm  ...>.... </mak:newForm>

Makes a form for creating a new object of the indicated type.

Example (personNew.jsp):

<mak:newForm type="general.Person" action="personList.jsp" method="post">
        <mak:input field="name"/>
        <mak:input field="surname"/>
        <input type="submit">
</mak:newForm>

At form response, makumba (controller) invokes the following methods:

1. By defining on_new*, the handler class gets the opportunity to validate/change the data. If the data is not correct, the handler can throw an exception to prevent insertion in database.

   handler.on_newTypeName(data, attr, db);
   

2. The standard Database call for insertion:

   Pointer created= db.insert(type, data);
   

3. By defining after_new*, the handler class gets the opportunity to do supplementary operations with the inserted record.

   handler.after_newTypeName(created, data, attr, db);
   

If the handler class is present but both handler methods are missing (on_new and after_new), the action is not allowed.

At response the following calls are executed (in this order):

PersonLogic handler_obj; // see handler discovery
handler_obj.checkAttributes(attr, db);
handler_obj.on_newGeneralPerson(data, attr, db);
Pointer created= db.insert("general.Person", data);
handler_obj.after_newGeneralPerson(created, data, attr, db);

<mak:addForm  ...>.... </mak:addForm>

Makes a form for creating a sub-object of the mandatory enclosing <mak:object> (e.g. a language of a student, an address for a person).

Example:

<mak:object from="best.Student s" where="s=$student">
    <mak:addForm object="s" field="languages"
    		 action="studentView.jsp" method="post">
        <mak:value expr="s.name"/>
        <mak:input field="level"/>
        <mak:input field="comments"/>
    </mak:addForm>
</mak:object>

This will call the handler methods: (the argument names are adapted to the example. Note the changed pointer argument in the methods.)

on_addBestStudentLang(Pointer student, Dictionary languageData, Attributes pageParams, Database db)
after_addBestStudentLang(Pointer address, Dictionary languageData, Attributes pageParams, Database db)

<mak:editForm  ...>.... </mak:editForm>

Makes a form for editing the object indicated by any of the labels of the mandatory enclosing <mak:object> or <mak:list>. Also linked objects can be edited through the same form.

Example:

<mak:object from="best.Student s, s.person p" where="s=$student">
    <mak:editForm object="s" action="studentView.jsp" method="post">
        <mak:input field="person.name"/>
        <mak:input field="person.surname"/>
        <mak:input field="graduated"/>
    </mak:editForm>
</mak:object>

The response will call the handler method: (the argument names are adapted to the example)

on_editBestStudent(Pointer student, Dictionary fieldsToChange, Attributes pageParams, Database db)

<mak:form  ...>....</mak:form>

Creates a generic form, that may call a handler method in response. It allows the JSP author to make any kind of form. They are suitable for more complex operations than new, add, edit.

Example:

<mak:object from="best.Student s" where="s=$student">
    <mak:form handler="doSomething" action="studentView.jsp" method="post">
        <mak:input name="xxx" value="s.person.name"/>
        <input type=submit>
    </mak:form>
</mak:object>

<mak:input... />

An input field to be created, depending on the makumba type of the field.

The difference between <mak:input > and normal HTML <input> in a makumba form are:

• <mak:input> produces objects prepared for setting/comparing makumba fields (e.g. Pointer, Date, Text).
• the fields produced by <input> will be available as page $attributes but will all be of type String
• the fields produced by <mak:input> are available separately as a Dictionary to the handler method

<mak:object from="best.Student s, s.person p" where="s=$student">
    <mak:editForm object="p" action="studentView.jsp" method="post">
        name      <mak:input name="name"/>
        surname   <mak:input name="surname"/>
        gender    <mak:input name="gender" type="tickbox" />
        dob       <mak:input name="birthdate" format="yyyy-MM-dd" />
    </mak:editForm>
</mak:object>

Fields of related records can be reference and edited as well, via pointers. In this (somewhat strange) example, one can edit the name of the capital city of the country of which person is a citizen, through the person edit form :

<mak:input field="person.citizenship.capital.name" />

Restrictions for different field types:

• fixed fields: cannot be edited
• relational and index pointer: cannot be edited
• timestamps (create and modify): cannot be edited
• subset, subpointer: cannot be edited as a field, only as a separate object

<mak:action>....</mak:action>

If the action URI of a form or deleteLink is more complex, possibly including other makumba tags, the action parameter of the form tag can be omitted, and the action URI can be indicated in a mak:action, anywhere inside the form tag.

Example:

<mak:editForm object="ins" method="post">
  <mak:action>memberView.jsp?person=<mak:value expr="p"/></mak:action>
...
</mak:editForm>

<mak:deleteLink>...</mak:deleteLink>

Produces a link to the page that will delete the object indicated by any of the labels of the mandatory enclosing <mak:object> or <mak:list>

Example:

<mak:object from="best.Student s, s.languages l"
	    where="s=$student AND l.lang.name=$langname">
	<mak:deleteLink object="l"  action="studentView.jsp">
		Delete <mak:value expr="l.lang.name"/>
	</mak:deleteLink>
</mak:object>

The response will call the handler method: (the argument names are adapted to the example)

on_deleteBestStudentLang(Pointer lang, Attributes pageParams, Database db)

<mak:response/>

<mak:response/> prints information about the results of the actions that were performed by the makumba controller (e.g. for a form submit or deleteLink): It either displays the message="..." parameter of the form tag (in green) in case of success, or (in red) the message of a uncaught LogicException resulting from Business Logic. Other exception types will provoke an exception page.

The unformatted message is available as request-scope attribute makumba.response. The jsp page can get hold of the message using e.g.

<% String s = (String) request.getAttribute("makumba.response") %>

Similarly, request-scope attribute makumba.successfulResponse is set only in case of successful action execution.

<% if (null == request.getAttribute("makumba.successfulResponse")) { /* action failed */ } %>

(A body-tag style (<mak:response>...</mak:response>) will be added later, to display different messages for different circumstances (errors). It will also be possible to get hold of the actual exception object. )