[REBOL] Re: RFC: Rebol Framework
From: robert:muench:robertmuench at: 22-Sep-2002 17:05
> -----Original Message-----
> From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]
> On Behalf Of Petr Krenzelok
> Sent: Sunday, September 22, 2002 2:54 PM
> To: [rebol-list--rebol--com]
> Subject: [REBOL] Re: RFC: Rebol Framework
> Heh, I just hope you don't consider my email being rant or so :-)
> I just tried to give some feedback :-)
Hi, no problem, feedback is welcome but should be aligned with the state
of work ;-). So yes, your points are valid and I will take them into
account once the framework is stable enough. I just consider the
feedback that makes sense (for me) at this point ;-))
I hope you made it to get the prototype to work.
> In fact, it's a bit sad more ppl are not
> attracted in something like having app/networking framework.
> Maybe it's just general problem of Rebol user-base - we are just few
I don't know too. I hoped that more people would have a look at it...
Maybe the prototype is still to basic. We will see.
> no, I just started the script, entered some info, pressed buttons and
> got app crash ... :-)
Ok, I really thought you meant some GUI layout stuff ;-)). What did you
done?
> to write some, I need to clearly understand how it works,
> what does it do, etc. :-)
Yep, we are going through this together :-)). I'm a big fan of how-to's
from people who didn't made the stuff as I know most of my implicit
assumptions but you don't as you saw when pressing the first button ;-)
> that answer my question, thanks .... In dbase we had to define which
> field is part of what index, to be able to perform fast searches.
Right, and the charm of the associative datamodel is, that this is no
longer necessary. The relations are decoupled from the data. The longer
I think about it the more I like the concept. It will add some more
development effort but that's ok.
> What do you mean by generic rules here? Imo it more relates to have
> profi-field style, accepting some kind of mask, etc. E.g.
> imagine field
> type for date entry, IP address entry, which automatically skips #"."
> (dots), etc. Users like it. So, above mask just means users are not
> allowed to enter other char than number, and other chars "-() " are
> skipped/can't be deleted, etc.
You are right. But I want to decouple the rules for an "IP address"
field from the code of the style. I would like to be able to attach a
set of rules for an "IP address" field. Something like:
ip-address-rule: [
seperator: "."
symbols numbers and "."
skip seperator
post-condition dns-lookup = true
]
This is a set of rules. I want a rule engine that can take thousands of
those rules and check them. Independent of the context the rules are
used for. You can use the same for data integrety:
address-rules: [
if delete than no-order-open = true
mandatory name, mobile
fuzzy-lookup name
post-condition address-lookup = false
]
This is a dialect a user can attach to some objects or constellation of
objects. I as a developer might not know all conditions and situations
to check, it could even be the case that you would like to have other
checks. So, I don't want to lock you in my code, you should be able to
tell my application what you want it to be.
> several of your answers refer to Rules. What do you mean by "rule" in
> regards to business object, its field, property, etc?
For an overview about the idea have a look at:
http://www.businessrulesgroup.org and http://www.ilog.com
> I don't like SAP. It has the most crappy language (ABAP) I
> seen so far. Too complex to maintain too ...
:-) Same with me.
> It sounds good. What about providing small example? Very
> primitive one, to your 1 - 5 points ... I am especially interested to
> understand first, how rules will be defined, if rules/relations can be
> later dynamically added during the system production life, what
exactly
> do you mean by "attributes" etc.
For this I have done the prototype ;-). Anything expect the rules can be
seen, but you can understand how rules could be applied.
> So, I still need to understand, what are going to be possibilities of
> rebol-framework system. I would like to see some open, not too much
> complex architecture, providing us with ability to define/express
> business relations, as needed.
That's exactly what it will do. Try for example to add a BO of your own.
Start the prototype and you will be able to fill-out a form and store
your data, set it into relation to other records. The only thing missing
is the rule part yet.
> It has to provide user/programmer with
> the feeling, like you have with Rebol - expressive freedom. As in
> relational model - you have to think in terms of relational-db
> capabilities. If such framework can be created, I am fully after it.
It's even more free than the relational model. Just add what you need it
and let the datamodel content grow. It will be a picture of your
situation. No need to know what an index, field, table, etc. is.
> PS: do you know anything about UML?
Yes.
> The question is, if we are not
> going to reinvent the wheels, as I read about similar BO
> systems, being described by language called UML.
UML can be used to model your BO you need and to see what relations you
have. There is nowhere mentioned you have to tranform this into a
relational-model. That's what is done mostly today, but it's not
mandatory. You could use UML to understand your problem, and use my
framework just to "implement" it with very few effort.
1. You would add all your needed BO
2. You would add all your needed relations
(the type not if 1:1 or 1:N, that's semantic)
3. You would add a set of rules for the semantic
And than just use it, your are finished. And the nice thing is, it will
be compatible with the rest of your BO. So, if you see you missed
something just add it on-the-fly. Robert