> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > On Behalf Of Petr Krenzelok > Sent: Tuesday, October 08, 2002 5:36 PM > To: [EMAIL PROTECTED] > Subject: [REBOL] Project introduction ... Re: Re: RFC: Rebol Framework > 1) I like objects - I always did - the path navigation is easy :-)
Hi, yes that's right but using objects for records has some disadvantages: - Extending objects isn't that easy - Objects take quite some space on disk (more than blocks) because empty object fields are saved too. Blocks just contain the name/value pairs that have a value > That's the first thing someone will have to explain me - why > naked-objects or RFM uses blocks and name value pairs? Is there any > advantage? Yes, it's a very simple and basic system. You might remember that I asked around what's the best pattern for storing data with Rebol. I tried objects and I tried blocks. For me blocks are more user-friendly. You can iterate through this series, you just can add a name value pair, you can nest blocks easly etc. With name/value pairs in blocks both pieces show-up to you the same way. Why make a distinction between the name and the value of a field? > 2) As you can see, I need some relations - each building has its rooms, > - typical parent child relationship. That relationship can be expressed > in RFM, if I understand it correctly, but what if child can have its own > child relationships etc.? Than just add it. My idea is that you have a set of relations: parent-child, used-by, responsible-for etc. Now you just add a relation from master to detail and select a type, that it. You will get a directed-graph of different relations. > 3) Can objects be extended in the real time by adding another > attribute? Yes, that's why I use blocks. And objects of the same class don't have to have the same structure. Only those name/value pairs that make sense are present. > Should I rebuild the rest of objects then, or just prepare > query engine that there can be some object field, which doesn't have to be > found with previous version of object? ;-) That's why I use name/value pairs. My idea is that in such a case the user can say: "Hey, for this record I need an other field. Let me see what kind of fields do I have available." Now a list of pre-defined fields will show up. Each field will have an explanation what it should be used for. If the user finds an appropriate field, he just selects it. If not you can add a new field, give it a description and use it in your current record. If you now see that you will need this field for all records, just add the field to the object-template. You see what I mean? > 4) I have to keep in mind, that my system will have to be > multilingual ... Fine, just add a label field to the field record and add different languages: [fieldname "surname" label [de "Nachname" fr "..."] description "Use this field for surnames of persons"] > Don't get me wrong - I started with few testing scripts, from the > scratch, as I need to understand from the very beginning how things > model for me, what is good and what turns into being > incorrect aproach, etc.. No problem, that's how I do it too. > I come from relational database world so things like associative > model of data, dynamic systems, etc., are rather new to me. Well, this will be the biggest step to do for you. I only know a few people that got it yet. Especially people with long RDBMS experience have big problems in understanding and seeing the advantages. Robert -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
