cristi (06:22 PM) : 
a big part of makumba code is based on "handler families"
the base is in org.makumba.abstr.RecordHandler and FieldHandler

the idea is that each field form a record knows how to do his part from an operation. for example
org.makumba.db.sql.RecordManager is a SQL table
org.makumba.db.sql.FieldManager is a general SQL table field
org.makumba.db.sql.charManager is as field of type char, which e.g. in CREATE knows to write char(size)
cristi (06:23 PM) : 
there is also e.g. org.makumba.abstr.printer.RecordPrinter
org.makumba.view.RecordViewer (i think)
org.makumba.view.jsptaglib.RecordEditor
which have FieldPrinter, charPrinter, etc.
Raul (06:24 PM) : 
huh....i have to start looking because i'm starting to get lost in so many classes
Raul (06:25 PM) : 
<censored version>the net is dead again</censored version>
cristi (06:26 PM) : 
for each RecordX, exists FieldX, charX, intX, dateX
exists a small text file, redirectX.properties 
Raul (06:26 PM) : 
ok ok...but why does every record have this??? 
cristi (06:27 PM) : 
let's say that you want to generate SQL that creates a table automaticaly
Raul (06:28 PM) : 
ok
cristi (06:28 PM) : 
the same hendle family will know how to insert, update and delete in that table
cristi (06:28 PM) : 
so we can't name it RecordCreator because it doesn't do only create, we name it RecordManager
Raul (06:28 PM) : 
ok
cristi (06:29 PM) : 
but we take the example of create, because it's simpler
Raul (06:29 PM) : 
ok
cristi (06:30 PM) : 
our RecordManager derives from org.makumba.abstr.RecordHandler, the father of all handler families (which, from hystoric reasons does MDD parsing also, as i remember) 
<correction>org.makumba.abstr.RecordParser, FieldParser, charParser, intParser, etc., that is, the "Parser" handler family, do the MDD parsing</correction>
cristi (06:31 PM) : 
any record has a number of fields, ok?
Raul (06:31 PM) : 
yup
Raul (06:31 PM) : 
wait.. what do you call a "record"???
Raul (06:31 PM) : 
a table?
Raul (06:32 PM) : 
a row in a table?
cristi (06:32 PM) : 
none of the above and something of both.
Raul (06:32 PM) : 
aaaaaaaa.....ok then :)
Raul (06:33 PM) : 
--- sedona.ro ping statistics ---
<snip/>
cristi (06:33 PM) : 
a RecordHanlder is something that handles a record in makumba. which is a row in a table, but in our case it creates the table
Raul (06:33 PM) : 
ok
cristi (06:33 PM) : 
so, let's say that for those fields, we make a FieldManager, which derives from FieldHandler. this is a "field in general"
cristi (06:34 PM) : 
so the father of all field-handles is org.makumba.abstr.FieldHandler
Raul (06:34 PM) : 
ok
cristi (06:35 PM) : 
ok, our FieldManager will have a method
String inCreate()
that will tell to the RecordManager "when you have to create a table, please add this stuff to the CREATE command"
Raul (06:36 PM) : 
aha...ok
cristi (06:37 PM) : 
and the CREATE command that RecordManager makes, becomes
CREATE MakumbaTypeWithDotReplacedWithUnderscore+Underscore and then for each field FieldManager.getSQLName() FieldManager.inCreate()
cristi (06:37 PM) : 
where getSQLName is another smart method of FieldManager (which probabily adds an underscore to the name of the field as it is in the MDD)
Raul (06:38 PM) : 
:))) ok
cristi (06:38 PM) : 
now, FieldManager is stupid and doesn't know how that CREATE part looks for each MDD type (int, char, text, date...)
cristi (06:38 PM) : 
and then we make for each type a class <type><family name>
cristi (06:39 PM) : 
dateManager, charManager, etc
Raul (06:39 PM) : 
aha...ok
cristi (06:42 PM) : 
along the types that you know (official, date, int, char, text), there exist some internal types:
ptrIndex is the key (the one that is named like the table)
dateModify is the type of TS_modify
dateCreate type of TS_create
ptrOne is any pointer 1-1 defined ptr and nothing after
intEnum is int{ blabla=1, gluglu=2} etc
ptrRel is pointer to a set in the base table
Raul (06:43 PM) : 
ok.....
cristi (06:43 PM) : 
do you understand all of this?
Raul (06:43 PM) : 
yes
cristi (06:43 PM) : 
I think there's more but is not important right know.

Raul (06:44 PM) : 
:)) 
cristi (06:44 PM) : 
so will have ptrIndexManager, dateManager, etc, ok?
Raul (06:44 PM) : 
ok
cristi (06:44 PM) : 
now, is pretty clear what each will do
what is interesting is that intEnumManager will not be different from intManager
cristi (06:45 PM) : 
in the creation of table context, right?
Raul (06:45 PM) : 
right
cristi (06:45 PM) : 
ok, we make a small file redirectManager.properties we write there
intEnum=int
cristi (06:46 PM) : 
ok?
Raul (06:46 PM) : 
ok
cristi (06:47 PM) : 
if we don't like the name of the type, we can write
text=bau
and make bauManager instead of textManager
Raul (06:47 PM) : 
I got this
cristi (06:48 PM) : 
another example, we can have a SQL engine in which the date is broken in date and time (we coldn't support this in QQL, but let's say we can). then we can write
date=date_date, time_time
and we make date_dateManager and time_timeManager
cristi (06:48 PM) : 
ok?
Raul (06:49 PM) : 
ok
cristi (06:50 PM) : 
ok, all this story with redirect<family-mame>.properties is havely coded in org.makumba.abstr.RecordHandler and any other class that derives from it can have this redirectX.properties file
we go further, the sets are not fileds in the same table, so they will have a RecordManager of their own, and no field handlers in our RecordManager. so in redirectManager.properties, we have
set=
setintEnum=
setcharEnum=
ok?
Raul (06:52 PM) : 
aha
cristi (06:52 PM) : 
ok, do you understand how the creation is done?
Raul (06:52 PM) : 
yes
Raul (06:53 PM) : 
this is the table creation ?
cristi (06:53 PM) : 
yes, thats how you go from makumba types to SQL tables
Raul (06:53 PM) : 
aha
cristi (06:54 PM) : 
in a similar way, intManager knows how to write a integer in an INSERT, dateManager a date, and so on (actually right now is easier because it is a preparedStatement, before it was pretty hard
Raul (06:55 PM) : 
ok
cristi (06:55 PM) : 
ok, there are operations that are not defined by all typeManager
for example there is onStartup() which is executed before the table is used. that one is defined by ptrIndexManager which searches for the maximum index whit the same DBSV
Raul (06:56 PM) : 
ok
cristi (06:56 PM) : 
then, at insert, ptrIndexManager adds 'the next key" in the record to be written. so the keys are generated in Java
cristi (06:57 PM) : 
ok?
Raul (06:57 PM) : 
ok
cristi (06:58 PM) : 
ok. because of that I renamed it ptrIndexJavaManager and I have in redirectManager
ptrIndex=ptrIndexJava
Raul (06:59 PM) : 
ok
cristi (06:59 PM) : 
let's say you come with a database that knows to make makumba indexes by autoincrement (allthough I don't know any that can do autoincrement form a given value). let's say that is called "raulsql"
cristi (07:00 PM) : 
in the case of raulsql ptrIndex can let SQL generate the indexes
Raul (07:00 PM) : 
ok
cristi (07:02 PM) : 
and in rest, raulsql is like any other sql, so we only need to rewrite the code of ptrIndex
we make a package org.makumba.db.sql.raulsql
we put there RecordManager extends org.makumba.db.sql.RecordManager
FieldManager extends ...sql.FieldManager
and a ptrIndexManager in which we write the code specific to raulsql
Raul (07:03 PM) : 
aha....ok got it...so different sqls have different classes....cool
cristi (07:07 PM) : 
so, in order to make a oracle driver you have to rewrite the types that are different there.
there is a file classes/org/makumba/db/sql/sqlEngines.properties in which for each SQL type it says what "tableclass" it uses (e.g. sql.raulsql.RecordManager), what JDBC driver it uses, etc.
textManager looks in that file because sometimes the only difference in handeling the text is in the name of the type. e.g.
mysql.text=LONGBLOB
db2.text=LONG VARCHAR FOR BIT DATA


Raul (07:08 PM) : 
ok.....
cristi (07:09 PM) : 
so, when you want to support a new engine, you either make a new handle family (org.makumba.db.sql.raulsql) or modify sqlEngines.properties, or both
you will see that sqlEngines properties contains other stuff, for ex SQL status for different errors:
mysql.tableMissing=S1000
mysql.lostConnection=08S01

cristi (07:10 PM) : 
ok, undestood how handler family works?
Raul (07:10 PM) : 
.....ok
Raul (07:10 PM) : 
ok....its staring to enlighten :)
cristi (07:11 PM) : 
ok, so (when hacking makumba) the first thing to do when you see a handler family, you look in redirect<family-name>properties to see how the type handeler are named
Raul (07:11 PM) : 
ok
cristi (07:17 PM) : 
fundamental handlers (in org.makumba.abstr.*Handler) do generic stuff for that type. 

e.g. intEnumHandler (which takes care of int{"a"=1, "b"=3} knows the alternatives from { } in the MDD. based on that, it knows if an int or String can be assigned to that intEnumu (if it is between {})

a intEnum<handler family> doesn't extend intEnumHandler, it extends Field<handlerFamily>. in order to have access to the info in intEnumHandler, it has a method  from which it can obtain it (I don't remember it's name)
cristi (07:18 PM) : 
got it?
Raul (07:18 PM) : 
more or less..... 
Raul (07:18 PM) : 
ok
cristi (07:20 PM) : 
actually there isn't any method. it's simpler:
let's say that a intEnumHTMLEditor wants to know what are the alternatives from the {} and display them in a HTML <select>
ok?
Raul (07:21 PM) : 
ok
cristi (07:22 PM) : 
ok, it extends FieldHTMLEditor, like any member of handler family, ok?
Raul (07:23 PM) : 
yes
cristi (07:24 PM) : 
FieldHTMLEditor extends org.makumba.abstr.FieldHandler. so, this has a public method Enumeration getValues()
that returns what it is between {}. of course that you don't have to call this method from dateHTMLEditor because date doesn't have {}
Raul (07:24 PM) : 
ok
cristi (07:25 PM) : 
the method is "seen" also by dateHTMLEditor because he also extends FieldHTMLEditor, which extends FieldHandler. but, surprize, if it calls it, recives ClassCastException
Raul (07:26 PM) : 
:))) aha
cristi (07:28 PM) : 
ok, the info from FieldHandler can be obtain also as a programmer-client of makumba through org.makumba.FieldDefinition interface. in general, everything that is in the root package org.makumba is visible outside makumba
Raul (07:29 PM) : 
ok
cristi (07:31 PM) : 
besides RecordHandler and FieldHandler, which are necesary to make handler families , its recommended that subpackages of org.makumba not to call each other, only using org.makumba.
e.g., if you need the data of a field in org.makumba.db.sql  it's good to use org.makumba.FieldDefinition not org.makumba.abstr.FieldInfo (which is a hystoric accident , much of what is there is in org.makumba.abstr.FieldHanler also)
Raul (07:32 PM) : 
:) aha
cristi (07:32 PM) : 
this way you maintain different parts of makumba independent, you can change one without changing the others
Raul (07:32 PM) : 
cool
cristi (07:34 PM) : 
e.g. org.makumba.view.jsptaglib, when it calls the Db doesn't call org.makumba.db, but org.makumba,MakumbaSystem
Raul (07:34 PM) : 
how do you say: kiss in swedish ?
cristi (07:34 PM) : 
puss
Raul (07:34 PM) : 
10x....now back to mak :)
Raul (07:36 PM) : 
ok.....i'm starting to understand this mak...and i'll have to admit that you did a good job.. i'm talking about the programming mode
cristi (07:39 PM) : 
back to handler families: 
- org.makumba.abstr.*Parser parsing MDDs
- org.makumba.abstr.printer.*Printer debug printing MDDs to verify if the parser works
- org.makumba.db.*Handler makes preparations for org.makumba.db.sql. i think they should be merged
- org.makumba.db.sql.*Manager we just talked. it's used to create SQL tables, read from them, write to them, assign parameters to queries, read results of queries
- org.makumba.view.*Formatter makes viewing of data in general (no HTML i think)
- org.makumba.view.jsptaglib.*Viewer makes HTML view for <mak:value>
- org.makumba.view.jsptaglib.*Editor makes HTML FORM controls for <mak:input>
that's all
