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

[REBOL] Re: rebol-framework: information

From: robert:muench:robertmuench at: 29-Dec-2002 14:24

> -----Original Message----- > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]] > On Behalf Of Petr Krenzelok > Sent: Saturday, December 28, 2002 5:26 PM > To: [rebol-list--rebol--com] > Subject: [REBOL] Re: rebol-framework: information > We will see ... that's one of things I didn't liked - very few > datatypes. The question is, how many datatypes is enough?
Hi, maybe datatype isn't the right word. What you actualy specify by providing a "datatype" for an attribute is its default behaviour. So for example: date! Will add a function to the label of the data field that, if clicked, will bring up a date-requester, further the entered date will be transformed to Rebol format before being saved in the database. So, datatypes are more to specify base-functionality.
> Should there be ability to define own datatype via some kind of
control
> function? (e.g. to use parse rules to define some custom datatypes)
I didn't thought about this yet. But it's possible.
> hmm, what does it mean? Does it mean you used RFM to define app data > structures? I just hope you don't use RFM itself to enter the > data? I am not sure it is good aproach, but I will have to see, if
sexy app
> offers enough comfort for end user to work with.
Yes, with RFM you don't have the typical "application to track bugs" approach. Instead you say: "I add bug-report BOT to RFM" and than you have this functionality within the RFM application (GUI). With this approach I want to include/integrate some of the "naked objects" idea.
> So far I prefer strong tool to define data dictionaries of BOs, share
them
> across internet etc. and let the UI part be completly separated task
... I don't think this makes sense. To create a good GUI is like a "black art" and it needs a good feeling for useability from the programmer. For example, I like programming but I don't like to spend to much time with the GUI. I know it's very important but other can do it better. IMO there shouldn't be to many different GUI/useablility approaches used/mixed in an application. That's why I would like RFM to build an appropriate GUI from the BOT definition. Since Cyphre created a first good GUI, we were able to merge our development stuff very fast without to many interface problems. We will see... At the moment the approach looks very promising.
> cool. I just hope you implement incremental update functionality as > Cerebrus does. Works nicely .... user does not need to download whole > new executable, but just differences, which are XORed agains current > executable, or something like that ....
Why not! IIRC the Cerebrus patch function was posted, right? If so, we will use it. The hardest part will be to update changes to the data-model...
> hmm, we will see how it scales .... I mean - storage mechanism.
I made some basic tests so these are far from any real life numbers but I think up to 10.000 records should be possible with the current approach. I further look into LDAP for a server side storage mechanism and Berkley DB (with DLL interface) for a local storage mechanism.
> Do you think that RFM could be used to rewrite IOS reblets into? > Would there be already any benefit? I miss ability of cross reblet
apis in IOS. That's what I'm missing too and that's why I started to work on RFM. My goal is to move the data from the current IOS reblets into RFM and use RFM as the single application that supports integration/assocication between every piece of data. This will need a multi-user storage concept, that supports parallel changing of data and later merging of it. Will follow after the standalone version works OK. Robert