🚀 go-pugleaf

I'm really at reillyp@gte.net.no.spam (without the .no.spam) if someone
wants to e-mail...

What I'm after:
Basically I'm after having a DFM that includes javascript for event handlers
(instead of TxxxEvent objects). I want to use XML to define the DFM-ish
part. An example might look like:

<?xml version="1.0"...?>
<!DOCTYPE xdfm SYSTEM "xdfm.dtd">
<xdfm ...>
  <!-- a script section for shared script functions; can act as the OnCreate
event for the main control -->
  <script language="JScript"><![CDATA[
    function DoSave() {
      // Validate that the ID edit is not blank
      if (Trim(editor.IdEdit.Text) == "") {
        editor.IdEdit.SetFocus();
        MessageDlg("ID cannot be blank!", mtError, mbOK, 0);
      }
      ...
    }
  ]]></script>
  <!-- The main control for this "unit" -->
  <TIsmFrame name="MajorEditor" caption="Major" Left="0" ...>
    <TToolbar name="MainToolbar" ...>
      <TToolButton name="btn1" caption="Save" onclick="DoSave()" />
    </TToolbar>
  </TIsmFrame>
</xdfm>

Currently my top-level controls are always TFrame-based (TIsmFrame is a
TFrame subclass that adds some functionality my app needs). The nesting of
controls is for the Parent:TWinControl-to-TControl relationship (ie in the
above, btn1.Parent = MainToolbar).

Anybody know of any tools to help me out? I've been playing with microsoft's
ActiveScript ax control, but that only gives me scripting support; I'm
hoping not to have to do all the control-to-activex stuff to support it. I
also compiled the SpiderMonkey dll (Mozilla's javascript engine), but it too
requires writing wrappers for everything...


More Description:

I have a database application. The database is defined from an
entity-relationship diagram, with the ER information (and the underlying
tables/columns) available in my app via some home-grown stuff (ERD is in XML
format; hand-rolled app uses this to initialize some TEntity, TRelationship,
etc objects in a generated .pas unit).

In general the application does two main tasks - it displays lists (of
entities - query based) and editors. Both the list window (there's only
one - it uses the ER info to tell what columns are available, etc) and the
editor window (see below) are actually TFrame subclasses (in the main app
window they dock in a TPageControl, and can be detached into a floating
window).

As I mentioned, lists (and filter dialogs for them, etc) are a piece of
cake; I have the schema available, and I have the higher-level E-R
information available; all I have to tell the list is which entity to
display. Because all lists look and feel the same, I only have (and need)
one list frame class.

The problem comes with the editor frames. While I have the E-R information
available in my program, editors aren't visually just a simple grid like
lists are - they have edits, combos, etc. So I need a unique editor frame
class (with different layouts, validation rules, and event handlers) for
each type of entity/thing that can be edited in the database.

What I'm after is extensibility. Our current app is "small", with only a
dozen-and-a-half or so entities. However, this is only the first part of the
program (for those interested: it has administrative functions for schools);
once this piece is done and out the door, we will add teacher functionality
(another dozen or so entities), and others (parents, students, possibly
district functionality too).

Because the E-R information is text-originated (xml), I could conceptually
embed the ERD in the database itself (as a memo) and build the ER info at
run-time when a database has been logged into. The ERD is an in-house
"extension" of the standard E-R model, giving us things like "nice" names
for entities, columns, etc, validation rules, etc. So I can (and do)
construct the main menu and a main "selector" tree at run-time based on the
ER information; add new entities and the menus/tree automatically include
actions to pop up lists of them.

So far all is cool and I can support different "version" databases (ones
with more/less functionality) because the definition of the functionality is
embedded in the database itself.

BUT: this doesn't allow embedding the functionality of editors in the
database. OK, conceivably I could embed .bpl files in blobs, but the
downside to this is that it takes a Delphi programmer to put that
functionality in there. What I'd REALLY like is to embed the same concept
(in particular, a dfm and it's unit code), but to have it MUCH easier for a
non-delphi programmer to work with. Kinda a "Delphi for Dummies"...

My idea is to use XML to store the control property values, and to use
Javascript for event handlers. I could put an Editors table in my schema
like:

    CREATE TABLE editors (
        ed_name    TEXT(25)    PRIMARY KEY,
        ed_definition LONGTEXT);

(I'm using Access for the database); now my E-R information could just
define whether an editor is supported, and - if so - what it's key is, like:

    <entity name="major" title="Major" ... editor="MajorEditor"> ...
</entity>

    TEntity = class(...)
    private
      FEditor: String;
      ...
    public
      property Editor: String read FEditor;
      ...
    end;

Now the list can tell if the user can double-click a row to "pop up" an
editor by checking if FEntity.Editor is blank - if so, no editing allowed
(eg: a composite list); if not blank it can use a "global" run-editor
function like ExecEditor(FEntity.Editor); this function would use scripting
support, an xml/dom parser, and would construct the editor from the
ed_definition field's XML text. No need for explicit editor unit creation,
and each database defines it's own editors.


Pat