Andreas Saeger wrote:
I'd rather see the GUI improved than abandon it as a bad deal and expect the general user to be conversant with SQL (any brand!).
You want to improve a GUI on top of a house of cards? Base is a
development tool. General User works with the forms and reports you
develop. I've seen quite often general users beeing intelligent and
patient enough to get behind the concept of a database, but wasting too
much time filing issues and developing macros (Dinbandhu on this list
and dba.devel, several users on oooforum.org). SQL is not the reason why
people give up using Base. SQL is easy enough. Particulary when seeking
help in a forum or list, SQL is easier to communicate than screenshots.
SQL can be copied and pasted. SQL is the most simple computer language
that helps you to build, maintain and operate *any* database. SQL can do
when the GUI must fail due to nested, conditional, recursive tasks or
when you need to use the database engine.
How far can you get with spreadsheets when you don't know the formula
language? From my experience some people get too far. They start writing
convoluted Basic macros because they do not understand what the
application could do for them. In Base you reach that point very quickly
simply because the application can't do it (calculate a date/time, link
foreign tables, copy a record, set default values in form controls,
filter by listbox, call a form, call a report, customize error messages,
click hyperlinks in fields, ... just to mention a few).
IMO Andreas is quite simply correct in the overall.
The features Andreas just clicked off can not be argued against as basic
fundamental requirements for a full featured database application
development environment, targeted to the small to medium business
market. I believe that is not an opinion, it is the facts on the ground.
For reference simply look to FormMaker, Oracle Forms and MS Access as
representative for what the market place demands.
Releasing a database application into this market that did not have an
actual import / export function, had no report writer to speak of, can
not designate an "opening form"..the list could go on .. is quite simply
analogous to releasing a word processor that had no support for mail
merge, no concept of a master document or use of templates. These things
can be, and should of been, viewed as basic cost of entry features.
One can ask how and why did that happen then. There is one answer that
is blazingly obvious, but no one seems to wants to touch it; that type
of product is not what was intended. DO NOT read into that a pejorative
- absolutely none is intended.
Software is designed to meet some set of requirements and that set is
constructed by whoever is commissioning the software - for contract
development it is the customer - for commercial release it is the
commercial organization based on it's collective understanding of what
potential customer's needs are - for hobbyist it is the hobbyist.
In the case of OpenOffice.org then who is actually setting the
requirements. The same group as all other software projects, those
commissioning the work - those paying to do it. Payment in this case is
the payrolls of three primary contributing organizations - Novell, IBM
and SUN. Those three organizations will take the code base from
OpenOffice.org, alter it as they see fit, and market it as their
respective products, Symphony, OpenOffice.org Novell and StarOffice.
At this point all one needs do is ask yourself a simple question - does
a FrameMaker or MS Access product fit into the market mix of those
companies user base. The answer is, IMO, no.
That is not to say this is an absolute - would they like a product like
an MS Access - sure. But at the end of the day real decisions must be
based on need and not like and those decisions well reflect in work
scheduling priorities. For example it is easy to see where the priority
has been placed - the reporting feature. Think again about the customer
base of the three organizations and one sees that this feature fits very
will into their market base. They therefore are willing to expend the
effort to meet it.
What does fit those companies markets in the database field are tools
such as java application servers and the associated development
environments targeted to corporate in-house development staffs. Netbeans
and Eclipse.
Does this mean that none of those features Andreas mentioned will be
added - no it does not - but it does mean that if one expects the
current mix of actual development groups, exclusively, to address them
they will be relatively slow in coming.
Frank has said this in a way time and time again - to paraphrase - "If
you want to contribute code, please do."
Any individual or organization is welcome to come fill in those missing
pieces and they would, I have no doubt, be warmly welcomed. The
organization has even taken pro-active steps to help that process happen
- their willingness to expand the API where it looks like it could help,
the entire push for the extension building capabilities, for example.
Of course this is ALL just my opinion.
It is also my opinion then that if Andreas, myself and whoever else,
really wants to see this full featured database development environment
package, targeted to the SMB market, become a reality we need to settle
down and decide how to help find, or develop, the resources to
pro-actively make it happen - it is at the end of the day appropriate
for this to be the case.
Respectfully,
Drew
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
