Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[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: and
> 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
> 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?
> 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