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

[REBOL] Re: RFC: Rebol Framework

From: petr:krenzelok:trz:cz at: 22-Sep-2002 14:54

Heh, I just hope you don't consider my email being rant or so :-) I just tried to give some feedback :-) 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 ....
>>there seem to be XY bugs ... >> >> > >What are XY bugs? Problems with coordinates? >
no, I just started the script, entered some info, pressed buttons and got app crash ... :-)
>>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 ;-)). >
to write some, I need to clearly understand how it works, what does it do, etc. :-)
>>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. >
Ah, now I understand ... more on that later ....
>>- 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. >
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.
>>- 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. >
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.
>Rules will be used. >
several of your answers refer to Rules. What do you mean by "rule" in regards to business object, its field, property, etc?
>To much SAP working, he? Rules will be used. >
I don't like SAP. It has the most crappy language (ABAP) I seen so far. Too complex to maintain too ...
>>Some overview found: >> >> >> > >Thanks for the link. IIRC I once heard about zachary, but I'm going to >have a look at it. >
Just don't spend your free time too much looking at old architecture. It is me who has to understand first, what your architecture offers ...
>>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. >
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. 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. 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. 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. Many systems can import it, etc. I don't know anything concrete about it yet though ... -pekr-