> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> On Behalf Of Petr Krenzelok
> Sent: Saturday, September 21, 2002 6:43 AM
> To: [EMAIL PROTECTED]
> Subject: [REBOL] Re: RFC: Rebol Framework
> there seem to be XY bugs ...
What are XY bugs? Problems with coordinates?
> pressing middle button, monitor, debug button - all crash an app.
?? Monitor is to fire up anamonitor, so no value for you. Debug is just
to probe some info to the CLI. Using the middle button you have to have
some data on the master and detail side to link. Anyway, I check into
that.
> There should be also some kind of simple
> example of how to actually use it.
Well, good idea: How about writing some short "how to get started" and
post it to me ;-)).
> I looked at sources and it lead me to idea, that I will probably
gather
> some screenshots of our old DOS Clipper app generator called Zachary.
Ok, what can be seen there?
> Very good production app could be generated by it. I especially find
> highly insufficient (unless I miss something) to define field type as
> only being a datatype.
As I wrote: This is just a very Q&D first move. It's not anything near
the business object dialect that I have in mind.
> In Zachary, we were able to define e.g.
> - how to initialise the field (e.g. by other field in db, joining some
> other fields in db, etc.)
Ok, but remember this is not a relational data-model. I don't have done
any query dialect etc. that will work on a graph-based structure.
> - is it part of index expression? If so, which one? 1, 2, 3 ...(index
> firstname + lastname + age)
?? What kind of index you refer too? The only ID used is an object id,
that's it. Searching will be field-based on a full-record base. So you
can search for any content in specified fields or in all fields.
> - can be edited?
> - is visible?
Yes, all GUI sugar. First things first. I concentrate to get the base
working than making it sexy.
> - VTG - variable to get - a cool feature - e.g. VTG("AB")
> allowed us to type only A or B chars (used for floppy sellection).
Choice?
> - mask - (999)-(999 999) - e.g. phone-number
No, generic rules will be used.
> - min - max value
No, generic rules will be used.
> - field type - could be other than just datatype! We had
> something like - M - menu, R - Report, U - user code
If possible I want to avoid types at all and only apply rules.
> - relations/validations - is field validated? If so - does it need to
> exist in child db? Or it must not exist? Can user add new new
> value, if it does not exist in child db?
Rules will be used.
> - updates - a cool one. e.g. - imagine typical storage management
> system. You have stock-db, you have material-entry-db, and
> material-outgoing-db. In your material-outgoing-db, you set
> field called e.g. 'amount, as updating field 'amout in stock-db, and
the
> equation is "decrease". You does not need to care of anything else -
if
> you give 5 pieces of mouse to some customer, the amount of mouses in
> your stock-db will be decreased. If you cancel order of your user, it
> will be added back to stock-db ...
To much SAP working, he? Rules will be used.
> - and - very important - conditions, conditions, conditions!
> conditions for access, conditions for update, conditions for browse
And again, I will use rules for this.
> - the fine thing was - you could first define .dbf in your
> FoxPro or so tool, then you could go to Zachary, name your procedure,
> press import, and basic definitions were created for you - then you
> just went to screen-painter, and imported desired fields. Assigned
given
> procedure name to menu field 1, and voila - your app was done ...
My idea is to just write a set of procedures and rules where these
procedures can be used. For example: You write a sum-function that uses
all objects of type rate, combine them with the data provided by objects
of type time-entry that are in relation to persons that have a
team-member relation with a project. Sounds complicates, I'm sure it is
and the challange is to find a way to make this kind of specification
useable through a dialect.
> - you could export your procedure definition to global repository -
wow
Yes, no problem because application logic is decoupled from data and
from the datamodel (!) :-))
> - repository based shared development in DOS times - we were kinds,
> noone could do what we did with Zachary back at that time.
We will see...
> Some overview found:
> http://www.incredibleprogram.com/html/zachary_overview.html
Thanks for the link. IIRC I once heard about zachary, but I'm going to
have a look at it.
> So, I don't understand a bit, where is your app framework positioned?
> What can be defined? What has to be maintained in code by
> ourselves? etc.
Ok, I try from what I have and where we will go to:
1. Users can define all kind of business-objects (BO).
- Business-objects have a class.
- You can define more than one business-object per class.
- The class definition uses paths idea to be able to
specify specializations for BO.
- Objects are build just from name/value pairs.
- Two records of one BO don't have to have the same name/value pairs.
2. Users can define all kind of relations.
- Same that applies to BO applies to relations.
3. Relations are the "semantic", BO are the data.
4. You apply generic functions on the datamodel that use the "semantics"
and the "data" for input.
5. You apply rules to define in which situation what makes sense.
6. You don't have a single application that does one job. You have a
datamodel, a set of functions and all these together are your "single"
application that will be all you need.
Robert
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
