(should be put in sentences and posted on www.makumba.org)
this is clearly the most original and
powerful part of makumba.
familiarity with SQL within HTML is well encouraged. groups of
mak:lists are nicely combined in a high-performance original way
$attributes are transformed into $1 OQL attributes in an easy
transparent manner
parametrized query fragments
(especially in orderBy, etc). what should be allowed? should such
parameters (attributes) be expressed differently than nomral
$attributes which become normal OQL query $1 parameters? should they be
declared?
the JSP taglib API is still not enough
for makumba's needs. makumba-specific JSP page parsing needed to be
introduced in the last taglib version
there are small features missing but the new architecture of
org.makumba.view.jsptaglib allows for easy extensions
of course many tag libraries (incl the
standard JSTL) know how to do
SQL queries or display tables (JSF) but none combine the two like
mak:list does (for better or worse)
the taglib was designed for JSP 1.1, since then JSP 1.2 and especially
2.0 added more features that, integrated in makumba, may simplify
makumba pages
especially the Expression Language (EL) of JSP 2.0 makes it much easier
to display values by using ${expression } notation
JSTL helps replace java scriptlets. makumba should be integrated more
with it
keep nice familiarity with HTML, while
taking good advantage of the MDD information. this is a strength of
makumba design
multiple forms are powerful and original
form annotations
expanding form interaction over more pages
chooser flexibility
see unfinished design above
form responders are lost at webapp reload
JSF (Java server faces) has excellent
design towards transforming web interaction into component-based
interaction. however, that goes too far into breaking the familiarity
with HTML forms, while bringing in a much less spread familiarity (GUI
component programming)
a simple, easy to read,
database-neutral data description.
a small number of types, that cover
most needs. more types would bring better performance, but create more
confusion
some concepts could have better names (more related to db theory): set,
internal set/pointer, etc
the initial ambition was to be
object-oriented: encapsulation is more or less done, but inheritance
and polymorphism are still not addressed. is this really needed?
subtyping (a database theory concept) is supported but can be made more
explicit
business rules. a data model should not only describe data, but also
specify rules on how it can be created and changed
the parser is a bit messy but it works
multiple-field uniqueness still not done
there is acute need for database theory
reading (to decide whether to have it object-oriented or keep it
relational, etc)
JDO supports (in Java standard, there are other tools like it) an
object-oriented way to describe data and deal with it, and make objects
persistent
a pretty straightforward API for
accessing MDD-generated tables in a database-neutral manner
the Dictionary usage for data arguments is a bit heavy (needs casts, is
not type-safe, etc)
maybe Database should be really called Transaction, or Connection.
maps MDDs to DB tables. when reading a non-makumba DB this is
especially useful
maps makumba types on their best representation in the host DB engine
uncertainty about object-orientation
(see MDD)
old, trusted code, using JDBC 1
there is a discussion on whether to use foreign keys or not
presently indexes are created for almost every field. this results in
the SQL engine not knowing which to use
database-neutrality made lots of
progress in the past years. JDO, JDBC Connector, even JDBC itself
do much better then they used to. dropping the db layer for one of
these technologies could be very beneficial
the JDBC API (currently at version 3 and going towards version 4) made
lots of progress since JDBC 1, most probably there are loads of
features that makumba does not take advantage of, including e.g. Rowsets
specify queries in a database-neutral
manner. but this can increasingly be done in simple, standard SQL.
OQL is also used to translate from MDD names to DB table names in
queries (by calling the DB layer)
we borrowed OQL
from the now defunct ODMG. the initial version of their OQL grammar is
still on the makumba CVS.
the ambition was to be object-oriented (see MDD)
an important feature of makumba OQL that distinguishes it from SQL is
the ability to refer sets easily (FROM general.Person p, p.addresses a
... instead of FROM general.Person p, general.Person->addresses a
WHERE a.person=p, though the second form should also work)
another important feature is the ability to analyze queries, including
type checking, useful during page analysis. even if we adopt a thrid
party technology, some form of query parsing will still be needed.
functions. they should probably keep
the object oriented manner (object.call(arguments) )
subqueries are badly missed
patchy, hard to add new features. one should start fresh from the
original OQL grammar and reimplement it to add functions and subqueries
database-neutrality made lots of
progress in the past years. JDO (which has its own form of OQL), JDBC
Connector, even JDBC itself do
much better then they used to. dropping or adapting OQL for one of
these
technologies could be very beneficial. JDO is explicitely recommended
by ODMG as the natural place to go
based on "secret attributes".
the design was so poor that it had to be patched with "checkAttributes".
the design led to a number of problems, including secret attributes
with identical names in different parts of the site
the design also hides the concept of session, which is important to
learn (and use) for developers. sessions can be used for more than login
the servlet speficication itself has a
good login design, and that standard login (and the design of its
integration in makumba) should be looked at first
there are other tools like jSai that seem to work in this department
bad design, mixture between logic and
controller.
thus the "clean MVC" part of the statement of purpose is still not well
addressed
it's clear that business rules should live with the data, maybe in MDD
files, maybe near them.
parts that are more dependent on the interface (on the way the form was
shown, etc) should be part of the controller
i think this part should be completely
restructured.
stuff that does pure data processing should move to "data model"
stuff that does data adaptation from and to the dialogs (forms) should
go to the controller
sessions should be visible to the model, the controller, or both
Jakarta Struts, JSF, EJB (e.g. for session design)
transparent for now. executes at every page access, via a servlet filter
see "business logic" above: stuff
that's
specific to the form should be specified in/near the JSP and executed
by the controller
not able to show different pages after form submission ("view
selection")
in general, not enough flexibility in treating the errors
Jakarta Struts, JSF
pretty original, building on the originality of MDD and JSP parts
interacting more with the
programming during development
"page summary" is still not
implemented, although the recent page analysis code makes it much easier
"pages and BL classes affected by an MDD" still not implemented,
although most of the tools are in place (page analysis, etc)