Re: [Phpsqliteadmin-devel] Be a developer?

[Steve D. <st...@wo...>]

Firman Wandayandi wrote:

> OK, actually I has another idea, that phpsla use more than one
> classes, I currently not finished drawing the UML yet, maybe some
> abstract explanation will be make it better. The idea is, to create
> some classes named: phpSLA, phpSLA_Error, phpSLA_Database,
> phpSLA_Table, phpSLA_Index, phpSLA_Trigger, phpSLA_View,
> phpSLA_Function, phpSLA_Result, phpSLA_Importer and phpSLA_Dumper,
> sorry if I missing some classes, the paper isn't here now. Those
> classes provide usefull methods, e.g phpSLA_Database::connect(),
> phpSLA_Database::schema(), phpSLA_Table::structure,
> phpSLA_Table::schema() an so on. So hold on for working the class, I
> think this will be better than it :-). Dunno that I'm will be busy or
> not this week, but I tried to finishing the UML first, and show out.
> 
> Comments? Suggestions? Any better ideas?

Are those all going to be individual classes?  Seems a little 
unnecessary to me to have so many classes for basic functions.  Besides, 
you're probably going to be calling most of them on the same pages 
anyway, so I don't see any reason to put them all in different objects 
and them remember which one calls what function.

Admittedly, PEAR's DB is split up a little bit, but it's still pretty 
simple -- DB.php, common.php and then sqlite.php.

I think something similar would help, too.  Make an sqlite-only class 
that handles all the queries, and then one for the HTML, output, deisgn 
and layout of the pages.  That way, anyone can copy/use our 
soon-to-be-awesome sqlite class without having to adopt our layout 
preferences at the same time.

Steve