World: r3wp

this is also just one approach, one strongly advocated for by Robert 
and if done right, it will be quite fast to work with

db-reactors is high priority, so I have to work on it now.

Pekr, tabbing is beign worked on right now

maybe db-*, as for naming convention, as I can imagine e.g. delete 
or update reactor for some non DB related purposes too?

Rebolek - cool then!

A basic example of how it looks right now:

f: view [
	form-panel: panel 2 [
		group 1 [
			title "Record fields"
			bar
			group 2 [
				label "Name"		name: field		; stored as name
				label "Address"	address: field	; stored as address
				label "Age"		age: field		; stored as age

    label "Skipped"	skip-field: field options [skip: true]	; not in the 
    list
				label "Ignored"	field			; not in the list
			]
		]
	] options [record: 'rec]
	group 6 [
		button "New" obtain 'form-panel add-record
		button "Save" emit 'form-panel update-record
		button "Delete" do [delete-record]
		pad
		button "<" obtain 'form-panel next-record
		button ">" obtain 'form-panel previous-record
	]
]


The 'rec is a record object, which is filled with data from the server, 
using the backend function, and when submitting, is used to gather 
data from the form and into the server.

what is 'skip for the field? Is it for tabbing to ingore the field?

The trick is that a panel acts like a record. You specify the record 
object in OPTIONS. Then any named field, checkbox, slider or whatever 
participates in the record unless the option SKIP is true.

SKIP allowed reading the record, but not writing back changes, such 
as a "last updated" field, which you don't want to write back.

then there are OBTAIN and EMIT reactors, which are siblings to the 
SUBMIT and ACQUIRE reactors.

http://94.145.78.91/files/r3/gui/db-reactors.r3

This shows a simpe skeleton of what it's made of.

The SKIP and RECORD options are scoping, so if you define a panel 
with SKIP, everything inside it is skipped on EMIT.

henrik there is already a decent db on rebol.org from Pavel... might 
want to look into that.

thanks

if you read his posts here, its quite interesting... probably just 
what we all want RIF to be.

RIF is RIF, let's wait for RIF, and not use pseudo dbs! Apart form 
that, doesn't Robert have SQLite for R3?

the point was really not to find a database, but to connect to it 
from the db reactors.

why ignore what Pavel has done?  why shoudn't his research contend 
for being RIF if it actually tackles the issues and works?

yeah... just saying that its a nice rebol-based experiment.

Henrik might as well use plain blocks :-) What are reactors after 
all? VID level actions, which unde the hood refer to some functions, 
so ... you could as well use rebDB or any in-memory aproach ...

right. it's those functions that would be nice to have written for 
various different DBs.

The thing is, that for multimedia, kiosk, tablet, multitouch etc. 
UIs, all that stuff is useless, and that is my point all the time 
:-) Henrik - one question - aren't you afraid, that all the stuff 
you work on, might be dismissed by possible change in architecture, 
when some other subsystems are going to be added? And also - how 
all this stuff is going to be optional? Look - even low-level R3 
now has various boot options, so e.g. someone can write and replace 
even module system. Now how pluggable (functionality wise) is new 
GUI going to be?

What if I don't care for your validation, your DB reactors? What 
if I am used to work with form and db my own way? Will I get one 
bloated gui? Carl was very picky for each single function to add, 
and now we are adding whole layers upon the GUI, which is still far 
from being finished.

Pekr, db-reactors and validation are optional features. Reactors 
are made using the MAKE-FACE-ACTIONS function, which specifically 
is designed to add a new aspect to the GUI in a way that doesn't 
interfere with its original functionality. And while you don't care 
about it, we do, because we need specifically to builds apps that 
use them, and I've missed these things in VID since I first used 
it. There's also that little detail about shaving off months of development 
and testing of large apps. The "bloat" you talk about would be around 
5 kb of code for now.

That's not bloat of code, but bloat of functionality I tam talking 
about. My experience is as follows - sometimes I like to use frameworks, 
but I don't like using frameworks just for the sake of frameworks 
themselves. Young guys did new SW for our old kiosks we installed 
around, and it seems so complicated (all xamp, web, replicated mysql), 
that they had to call their guru to set-it up.

I just wanted to say, that sometimes it is easier to not use some 
framework, because 1) each framework can do only certain stuff 2) 
you have learn this stuff 3) more complicated things are difificult 
to do. Goog example is that overhyped DB for Rails, don't remember 
the name. In 5 minutes, I needed more complicated set-up, and the 
answer? Bad excuse about framework being good just for certain things 
... no, thank you ...

Bloat of functionality: That's not the point of these frameworks. 
The point is to make certain rudimentary things quick and easy to 
set up for anyone trying to write a GUI. I'm pretty sure that once 
you've fixed the 657283th bug in a javascript/HTML webform, you will 
really wish this was already worked out for you.


If the frameworks don't work out for you, then they are poorly written.

It is often about the clash of how we are used to think, and use 
some functionality, about our workflows. If everything is gluable, 
well then. I would not just like to see, that each style has tonnes 
of fields, to support upper layer frameworks. I hope you keep it 
streamlined to some flags, and custom data fields ...

btw - would it be (let's say later in the process) possible to introduce 
some other form of release? I mean - I would like to look into sources, 
but it is flattened recently.

I don't want to push you to Tortoise, etc., but there surely be some 
distribution form of the GUI? I mean stuff separated in files, etc. 
It helps studying some stuff

You have some rules that you need to follow in any framework, otherwise 
they won't work for you. In the case for, for example db reactors, 
you need to know about the specific options, the rule that fields 
must be named for them to be used and how. But really, there are 
only few rules and once you've worked with attaching database records 
to a form, in a manual  way versus this way, you probably don't want 
to go back.


The other thing is an illusion of control with absolute flexibility 
without a framework. It simply lengthens development time and introduces 
bugs (something that we keep overlooking, eh?), and generally keeps 
the customer unhappy.

I can make a zip file of the sources later.

or at least small changelog?  :-) Is it difficult to provide in recent 
stage of development? E.g. when you release new version - what actually 
changed, what should be tested, etc.?

changelog needs to be done by rebolek. I don't have an overview of 
the changes happening right now, of which there will be some more.

You are trying to tell me, that DB record linkage to form is dependant 
upon certain naming of the fields?

it's logical to bind the name of the field to the record name, yes.

Direct link of form fields to db rec is imo the worst illusion I 
have seen :-)

oh, no, now I lose all flexibility!
, but no you really don't.

I worked with similar aproach in Clipper, and most of the time it 
was not flexible enough ...

you solve this in the functions that link to the database.

Can anyone else confirm that on Windows (at least on Win 7 64 bit) 
the last r3.exe that Henrik posted a link to here, pops up a security 
dialog ("Open File - Security Warning")?  This isn't the UAC dialog 
that you get when you run an executable as administrator, btw. Other 
r3 executables that I had lying around don't do this.

yes, I can confirm that ...

Henrik, thanks for posting your db-reactor ideas. Is there a reason 
not to use the standard REBOL series func names for actions. i.e. 
insert/change/remove/select rather than add/update/delete/get? Another 
option would be the names from CRUD. 


What does the underscore in your _data naming convention indicate?


I need to look at your validation design again, to see how things 
work together.

the names are up for grabs, so we can discuss that now.

well, I guess using db nomenclature is better when refering to db 
services... no?

I don't like the underscore prefix, but this is Robert's idea.

the _data option is a multi-field field formed as a map!, to allow 
extending a table, without adding columns in the table.

is CRUD not more encompassing to persistent storage in general, than 
just SQL?

I mean thereby the SQL terms insert/change/remove/select

Regarding the _, we can get rid of it. I use it to "indicate" private/internal 
stuff, you shouldn't mess around with.