Re: [binarycloud-dev] Practical use of r2

[John D. <jo...@we...>]

On Wed, 15 Aug 2001, Phillip Smith wrote:

> 
> 
> Specifically, there is an existing open source project [ Ministry of
> Truth - http://mot.sourceforge.net ] that is no longer being actively
> maintained.  I am giving serious thought to picking up development
> because I've not found any other software that fills the same niche,
> and because I've spoken with the original author who has encouraged me to
> do so. The problem with this is that I am not comfortable with the way its
> idea/essence is currently implemented, and would really want to rebuild it
> from the ground up (the TODO and feature list is long, and it seems pointless
> to try re-inventing the wheel with what's there).  For those that don't
> care to visit the website, MOT currently allows one to group db tables/fields
> relationally into larger more useful things (e.g project tracking,
> hardware/software inventory, etc.), all without having to know anything about
> html/php/sql (given that it was originally written in 1998 and includes its
> own built-in XML parser, it's still an impressive and usable piece of
> software).
> 

There is actually some overlap as far as which capabilities each project
provides. I think we've implemented a lot of MoT's lower-level functionality,
but there are definetly key pieces missing, notably user (read: web based)
creation and management of tables (which means user creation of entities). At
this point all entities are created by the developer at development time.
That's a pretty big jump.  

I could almost see MoT as filling two roles: both the role in which it is
currently used, and for actually simplifying development of binarycloud
applications, by allowing developers to create tables and entities through a
nice interface. 


Here is the MoT features list, with my comments after each:

The ability to create and modify databases, tables, fields, and permissions,
all from a point and click, web interface. 

(jd: I've never thought of having an entity represent a tablespace as opposed
to a table. I'm going to have to think about this, but it would probably make
an interesting extension)

Support for links between tables. Jobs may be linked to users, equipment, and
software. People may be linked to department, companies, contacts, and
machines. 

(jd: entities are structured objects. One entity can nest another, partially or
fully, so this is part of what r2 will provide with the entitymanager. Giving
users the ability to define their own entities would be another interface that
doesn't exist now, however)

Support for multiple users and read, add, and modify permissions for each user
for each table. 

(jd: the permissions system conceptualized for bc is amazing, incorporating
very complex session management and a notion of roles (user-created definitions
of permissions). it's also vaporware at the moment)

Support for sorting and restricting every table to a fully configurable set of
fields (sort a list of jobs by priority, close date, or tech, or restrict the
same list of jobs to a specified contact). 

(jd: this is completely provided for by our lister class, another forthcoming
part of r2. It also does filtering on a per-field level)

Support for actions, which are custom scripts automatically fired by specified
database actions (adds, modifications, etc.). This is immensely helpful for
implementing things like email notification and timestamping. 

(jd: we have the notion of events in the entitymanager, which are
add()/delete()/set()/get() etc.. A developer can associate functions to be
called with a specific entity's events. The way we do this now is by
subclassing and extending the base entitymanager for that specific entity. This
might be too heavy-handed so another approach may be necessary, hrmm..)

Basic support for writing custom sql queries. This will eventually include a
custom query page but is very helpful now in the creation of actions. A sample
mot_sql query that joins three tables together and grabs a value from the third
table looks like: select {People}.[email] from {Jobs} <Users> <Personal
Information> where {Jobs}.[id] = $row_id 

(jd: we have a standard set of queries associated with every entity that are
generated as part of a developer's 'make' process. There isn't a clean way to
do custom entity-related queries right now, but this only requires minor
re-engineering. Instead of having people write custom queries, it would be much
cooler to have them write XML-based views, at least for selects)

Support for importing and exporting database schemas. 
(jd: no idea. I hate databases anyway. Especially Oracle.)

Support for database-specific help files. All you have to do is write the text. 
(jd: see above)

(jd: just kidding. We currently can export any entity to XML, and from there an
XSL transform takes it to CSV or PDF. Pretty fucking slick. You can export
either lists or single objects.)

Basic searching capabilities. 
(jd: not something we've ever needed in our application, so I haven't really
thought about this. you can effectively 'search' a lister with filters, but not
more than one entity at a time..)

CSS support for configuring the interface. 
(jd: no idea)


I think there is a good synergy between these two pieces of software. I
definetly think you'd get more (as long as you're willing to wait :)) out of
binarycloud than you would out of something like Horde.. 

-- 

John Donagher
Application Engineer, Intacct Corp.

Public key available off http://www.keyserver.net
Key fingerprint = 4024 DF50 56EE 19A3 258A  D628 22DE AD56 EEBE 8DDD