Project introduction ... Re: Re: RFC: Rebol Framework

Well ... I will start from another end. I am currently busy (I was busy even before ;-), as I started some preparation work for my part time job. The thing is - I will desing our regional info system for my friend's local area info centre. It will start small, it will feature initially tens or hundreds of records, but what I will need is well thought out system relations. There will be db, IOS like aproach, plain text files, representing various items. There will be three levels of system developers - me, coder, web (not only web) designer, and IC ppl entering data. There will be also several output "devices" - web page of our town, other web portal, kiosk systems, presentation CDs, etc. I also need to divide work amongst various ppl. You surely remember our yesterdays discussion about rebol-server-pages aka build-markup. That kind of work is not flexible and abstracted to my requirements. I can't imagine 1) dropping my web-designer as I was suggested by Martin to do :-) 2) and that's why my cooperation with web-designer has to happen in different way. In the initial stage, let's suppose part of the system, which will hold accomodation info ... The rough idea is that I will create small reblets allowing my IC friend Alena to enter her data into. The reblet will import current db into text-list, and allow her to add/edit/delete. I have yet to decide, if I will keep central db and add some button to reblet to tell what info gets synced where or I will have distributed db and import/export from/to different location (e.g. paid system, where company X doesn't pay to be presented on kiosk no. 3) Then there is designer, Martin, who does design. I already outlined, that I have no intention in intermixing my rebol code with his html one. Thanks to DockKimbel and Chris I know that there is a better way - modular aproach to html and custom tags. I think that I will go similar route, eg.. <%table_2 [ module: table needs: 1.0 ; ensures the server engine will be able to parse html section ... rows: 10 cols: 2 ]%> <%/table_2%> I have yet prove to myself it can work, but the idea is to develop server engines (modules), which knows how to parse = handle stuff in-between. So, it is upon, me, if module 'table, in version 1.5, exposes more api to web-developer or not. It would be even cool, if Martin's WYSIWYG tool allowed me to create plug-in (dialog box) to enable him to config it. That way, he has more freedom to introduce nearly whatever layout to the section he likes to (of course, it still needs to be parsed though :-). The interesting part, related to framework itself, comes in Alena's department. My problem is - I am an average coder, what Cyphre codes in 5 minutes takes me an hour and still my solution will not be so elegant :-) And so, to properly understand some principles, I have to start my own way first. What I would like to create is really dynamic system, where IC ppl could extend various object attributes, but I am not sure it will lead so far. I can somehow feel that Robert's framework offers something like that, but it still crashes on me sometimes and I still don't know how to use it, where to start. Let's suppose following objects (they are far from being complete), representing first area of system - accomodation info (they serve as templates)... obj-accomodation:: make object! [ id: name: Street: Town: Zip: phone: [] fax: email: [] www: category: ; e.g. chalet, pension, hotel, motel, etc. maps: [] ; e.g. 001 200x200 100x100 , where 001 leads to some %mapblabla.jpg cell-signal: [] ; can you use your phone? photos: [] ; divide into four years seasons? description: {} internet: false rooms: [] ; can have 0 to X rooms .... ] obj-room: [ id: placement: ; central building, etc. category: no-beds: toilet: shower: tv: cable-tv: phone: internet: fridge: price-bed: price-inc-breakfast: description: ] 1) I like objects - I always did - the path navigation is easy :-) 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? 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.? 3) Can objects be extended in the real time by adding another attribute? 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? 4) I have to keep in mind, that my system will have to be multilingual ... 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.. I come from relational database world so things like associative model of data, dynamic systems, etc., are rather new to me. I know I will further test RFM, simply to map my thoughts to someone's else's. As I will progress, become more powefull at the ground, I can look once again how do I differ from other's pov, and eventullly scrap my own solution in favor of another one, e.g. RFM. So, any kind of enlightenment is appreciated here, as it can form my pov and eventually save me from unnecessary work :-) So, sorry for long post ... I just hope, that in the end, the project will turn into being fun - it is one of those kind of projects for non-profit organisations, where there is no big company to push you to do it that way or other way and so place to learn something new for me ... :-) -pekr-

Yes! :) Because one can alter the block at runtime! For example, adding more fields or removing them. That allows customising each record.

I'm working on that kind of thing, with bidirectional links expressed as containment. Something like: [Teacher "A. Teacher" Room []] ; Last block contains next block: [Room "K5" Teacher []] ; Last block contains first block.

No! And if another object points to the object, you're going to have problems. That's because the other object will hang on to the orignal, when you change it. Andrew Martin

You can do so with object too. Object = template you load from your repository. If you want to extend, you can extend the class (block of set-word and value pairs), and instantiate the object (load block into context) once again :-)

Uh, I didn't mean something like that, but well, I don't understand above anyway :-) Seems like some of never ending recursion :-) What I also don't like about RFM so far is - that it stores field names with each record, which I see as redundant, unless it has its own purpose I can be not aware of. (e.g. that each record can have variable set of fields)

I meant something bit different - not real rebol objects, but e.g. earlier mentined accommodation class. System admin (not necessarily rebol programmer) can say to himself one day - hey, this hotel has cinema inside. Where should I put that? So he goes to "object" repository, selects hotel class, and adds/describes "attribute" (field) of 'cinema-inside? type e.g. That was what I meant by ability to extend object during the system life-time ...Of course there can be consequences to it, like such field not existing in former records - so ti may cause some difficulcy to query engine e.g. -perk-

mentined accommodation class. System admin (not necessarily rebol programmer) can say to himself one day - hey, this hotel has cinema inside. Where should I put that? So he goes to "object" repository, selects hotel class, and adds/describes "attribute" (field) of 'cinema-inside? type e.g. That was what I meant by ability to extend "object" during the system life-time ...Of course there can be consequences to it, like such field not existing in former records - so ti may cause some difficulcy to query engine e.g. I want and need users to be add or remove fields. A fixed system won't be better than what we've got all ready.

fields or removing them. That allows customising each record.

repository. If you want to extend, you can extend the class (block of set-word and value pairs), and instantiate the object (load block into context) once again :-) Unfortunately, one has to then hunt for the other instances of the object in the net and delete them. It's far more simple and quicker to just clear the block! (if necessary) then add in fields (Name Value pairs) as required. Sure, if you're just storing a tree of objects your system will work, but not if one has network of values. Andrew Martin ICQ: 26227169 http://valley.150m.com/

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

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?

rooms,

expressed

own

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.

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.

to be

;-) 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?

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"]

No problem, that's how I do it too.

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

Of course - but I have to yet see (and understand), what advantages it can offer, and mainly - how such advatage can be used for the good ...

what do you mean by "network of values"? -pekr-