Recent changes to feature-requests

Automatically set focus to first form field

Matthew Patton — Fri, 10 Oct 2003 15:41:25 -0000

Could possibly have JS do this for us?

Allow error messages for radio buttons

Matthew Patton — Thu, 02 Oct 2003 18:00:05 -0000

The problem here is where to display the error message.
Possibly have a function in the view that can be
called that means "place error message for this field
here"?

Switch from PEAR to ADOdb

Matthew Patton — Tue, 16 Sep 2003 17:48:09 -0000

ADOdb seems to be a better DB abstraction library,
allowing metatypes (which doulos's own metatypes can be
based on) and much better performance (faster queries),
as well as abstractions for handling transactions and
sequences. Hopefully this will totally eliminate all
special cases for each DB type in the DBModel and
DBModelBase, and will allow Doulos to support as many
DB's as there are drivers for ADOdb

Debugging programs written on the framework

Matthew Patton — Tue, 16 Sep 2003 17:45:07 -0000

Often when a bug comes up in a program written on the
framework (like when the programmer uses the framework
improperly) PHP reports the problem as being in the
framework file because that is where the problem
triggered an error in PHP. If there could be some sort
of heavy-duty checking in the framework to ensure that
the programmer is using it properly that would be a
great help to newbies who are unfamiliar with the
framework. Potential problem: all this checking will
make the framework slow. Perhaps can be avoided by not
doing the checking if a certain flag in the framework's
config is set to false

In View::tableRow(), make modification of indiv tags possibl

Matthew Patton — Thu, 28 Aug 2003 18:06:15 -0000

Probably need to just check if element data is an
array, if so use the extra element to insert the stuff
to follow the TD (like COLSPAN or something)

Overhaul Model

Matthew Patton — Thu, 28 Aug 2003 15:53:53 -0000

The interface to the Model needs to be overhauled.
There are a number of issues:
1. Non-standard functions (parameters vary, see init()
vs get())
2. Long complicated functions make it very hard to
override the classes (see DBModelBase::get()). What if
I want to have different DBMS's managed by overriding
DBModelBase instead of conditionals as we have it in
0.1.1?
3. Non-standard treatment of $ptr (sometimes if..then,
sometimes switch)
4. Greater abstraction is possible in DBModelBase: can
have specific functions called (see the dilemma in
SampleFrontCtrl::exitApp()), can also abstract the
loadObj() calls in FormModel and in DBModel
5. Need to make $ptr case-insensitive
6. DBModel/DBModelBase is complicated in general,
perhaps there are ways of making it more elegant?

MySQL support in the model

Matthew Patton — Mon, 25 Aug 2003 14:47:11 -0000

MySQL is so commonly used that there needs to be
support for it in the DBModel and DBModelBase. (Need
it also for the sample app to run on SF)
Possibly have two sets of classes inherited from these
classes for each kind of DB? Or just have the type of
DB be a configuration option in the constructor to DBModel?

XML or text-based configuration files

Matthew Patton — Thu, 21 Aug 2003 16:07:56 -0000

Currently the ConfModel class for handling
configuration data is very primitive and just includes
another php file with the values set in it explicitly
for the configuration.
Will eventually want to make it possible to use XML or
some other text-based system for specifying
configuration information.
This will have benefits not only in the small amount of
configuration that is needed for Doulos, but also for
any other configuration that is done for the
applications built on Doulos (for which it will be
important to be as user-friendly as possible)

Get rid of using tables for page structure

Matthew Patton — Thu, 21 Aug 2003 16:02:23 -0000

In View (esp View::writeBody()), tables are used to
structure the page and not something more professional
and robust like DIVs

A user must be able to generate every possible SQL query

Matthew Patton — Thu, 21 Aug 2003 16:00:39 -0000

Currently DBModelBase::getQueryStr() can only create a
certain subset of the queries possible by taking the
associative array $query as a parameter.
The user must be able to make ALL possible queries so
that he can always reap the benefits of the DBModelBase
(i.e., organized results, type conversion, etc)
Will involve rooting through the documentation for
PostgreSQL and any other DB we want to support and
figuring out how to do each query.
Will get sticky when we think about nested queries and
UNION queries and the like.