World: r3wp

ok, triggers can't be used, as they only work on panels. There's 
too much work involved in making them work for individual faces, 
it seems.

Making a trigger work on a face would require making the face contain 
other faces. Which would turn it into a panel.

BrianH, yes, that would be a work around, so I'm not using triggers.


I've written a GET-DB-PANEL function now that fulfill the specs, 
including SKIP, TABLE, _DATA, scoping, etc. This function is custom 
to RM-Asset, so I'm not sure we want it in the R3 GUI other than 
as an extension package.


Also, I've written an EMIT reactor that emits the panel in GET-DB-PANEL's 
object format as an SQLite record (predefined object).

I'm using options for now along with GET-DB-PANEL.

What this shows:

- Writing reactores is easy peasy.
- Using reactors is even easier.

- Doesn't break anything in the R3 GUI, if you GET-PANEL instead 
of GET-DB-PANEL.

An example of how this is used:

rec: make object! [] ; the SQLite database record object

view [
	form-panel: panel 1 [
		id: field options [skip: true]		; write-only field
		name: field				; stored in the object as 'name
		age: field				; stored in the object as 'age

  note: field options [_data: true]	; both these will be stored in 
  the _data map!
		bytheway: field options [_data: true]
	] options [record: 'rec]
	button "Emit" emit 'form-panel
	button "Submit" submit 'form-panel %form.txt
	button "Acquire" acquire 'form-panel %form.txt
]

So when you press Emit, 'rec will be set to:

make object! [
	name: ""
	age: ""
	_data: make map! [
		note: ""
		bytheway: ""
	]
]

If you press Submit, this object is made:

make object! [
	id: ""
	name: ""
	age: ""
	note: ""
	bytheway: ""
]

and is stored on disk with the name %form.txt


If you press Acquire, the above mentioned object is automatically 
loaded from disk and into the form.


Still need a one-liner for loading SQLite data into the form. Going 
to work on that now.

I know that you guys are doing some stuff for real apps, but those 
concepts really seem very preliminary, and kind of high-level in 
relation to GUI itself. Maybe this does not even belong to GUI itself. 
I alway hated, when GUI dictated me, how should I work with my data 
.... it is always like that - you come up with just one method, of 
possible tonnes of other methods of data to form relation handling. 


We don't have tabbing, focusing, accelerator keys support, unicode 
support, layers, transition effect, rich-text and draw probably still 
need some improvements,  etc., we don't have any more complex style 
to prove our GUI allows to be extended flexibly, so I think that 
solving how to handle data from SQL at this stage is very very preliminary 
:-)

This is just my opinion :-)

Robert needs this for an application as soon as possible. I can assure 
you that if things like GET-PANEL and SET-PANEL aren't working correctly, 
getting data in and out of the UI will be quite painful, worse than 
digging through an R2 face tree manually. But fortunately I spent 
these few hours yesterday, making sure it's easily done in a single 
line of code.

so, why not to fix get-panel and set-panel then? :-)

fix? could you rephrase that? I already fixed them.

Anyhow, a form like this:

http://rebol.hmkdesign.dk/files/r3/gui/196.png

can be set in one line of code and retrieved in one line of code.

Nice! Henrik - one question. In Zachary app generator I used in DOS 
era for Clipper, there were basically two options, of how to initialise 
form - 'new, and from DB. Simply put - you set-up new record, and 
you want to have some items to be pre-filled with some default values. 
Is that possible with your concept?

Nice "skin" too :-)

I used Genifer for dBase and Clipper

Currently the form is bound to one record. Good question, btw. on 
new item. It's simple to do in principle, but I think it requires 
a clearly defined set of functions (reactors) for simple db operations:

I guess one wants these reactors (names not finalized):

emit - get data out of form to table. Done.
obtain - get data from table into form. Done.
next - next record
previous - previous record
first - first record
last - last record
new - new record
delete - delete record

In Zachary I really liked one feature. There was subtale, where you 
defined On-update ... simply you could add multiple to-update records. 
So - you e.g. added 5 iPhones to stock. The field has registered, 
that on-update updates stock amount. If you deleted order, it was 
automatically withdrawn from the stock ... etc.

there is also the case for displaying multiple records in one form. 
I've solved that in the VID Extension Kit, by providing an alternative 
form with fields that are disabled. clicking a checkmark enables 
the field and lets you set a value. when the value is set and you 
submit, the involved records have that value updated.

When will we be able to build more complex styles, as tabs, grids? 
I mean - is all infrastruture inside already?

I do remember how I disliked one simple draw block (one gob) to represent 
a style. IIRC BrianH said, that multiple gob styles are possible. 
Would that be a hack? Or is method already supported?

You still use a single draw block, although you can switch between 
different draw blocks for one GOB. One thing I don't want, as a style 
writer, is also to have to manage the GOBs as well. That makes it 
significantly more difficult to write styles, but I suppose there 
will be special styles coming around where you can use dialects like 
MAKE-GOB to freely define what's inside that style.

tabs: we already are able to switch between panels and need a button 
panel for doing this.
grid: big job and cyphre has already volunteered. :-)

ah, fine. Hope that he will use some of mine outlined Rebgui grid 
- virtual rows/columns, so that you can use raw data block directly 
from SQL query, no need to rebuild it into special block. Very usefull 
...

btw - docs are geting better and better. Draw and Shape docs were 
added recently. Gobs too ...

Has anyone taken a look at Active Records? It looks quite interesting.

http://ar.rubyonrails.org/

This is quite this kind of nonsense I thought we could avoid :-) 
You simply often might find the case, where it will not fit your 
situation, and then docs say - you can't do everything, using the 
concept. So then you are left with some usefull, but not-in-100%-cases 
usefull case, and between the raw solution. IIRC Chis has similar 
solution with his system? I don't remember the name .... however 
- this does not belong in the GUI group, and this is exactly where 
I thought your form  abstraction aproach will lead you :-)

To carl concerning the timing problems noticed on my computer i got 
those result (windows seven; CPU core i 5 750, DRR3 1333 Mhz; R3 
a 97)

>> dt [loop 10 [wait 0.0001]]
== 0:00:00.000016

>> dt [loop 100 [wait 0.0001]]
== 0:00:00.000084

>> dt [loop 1000 [wait 0.0001]]
== 0:00:00.000783

>> dt [loop 10000 [wait 0.0001]]
== 0:00:00.007763


As you can see on my coputer my timings are lower than expected so 
sthis issue is related to CPU horse power.

Not the problem, try this instead, it should return around the same 
time, not the case.


>> repeat i 6 [print [n: 10 ** i "x" j: 0.1 ** i tab "=" dt [loop 
n[wait j]]]]
10.0 x 0.1			= 0:00:01.000137
100.0 x 0.01			= 0:00:01.00159
1000.0 x 0.001		= 0:00:01.023774
10000.0 x 0.0001		= 0:00:00.044802 (strange)
100000.0 x 0.00001		= 0:00:00.459103 (here too)
1000000.0 x 0.000001	= 0:00:05.503772

Conclusion, never use timer below 0.001

I'll go with Carl's conclusion: It's a bug.

hmm... when writing a reactor, you can specify any-type! as an argument, 
but GUI parsing halts when encountering a path! for that argument. 
Does anyone know if this is a DELECT thing?

yep, delect is used for

path are evaluated by delect, they can't be used as parameter.

lit-path works

ok, thanks

strangly, get-path! works too

I didn't think that it wouldn't work, since this is inside the dialect 
and so the path shouldn't be evaluated.

well, word are evaluated as-well if they are used for parameters

if they wasn't we counld not use variables in our draw blocks

The dialect itself evaluates some stuff.

Henrik, I admit I have not read the whole discussion but I have a 
question:

Does this system caches data somewhere before updating the record(s) 
or data is immediately written on the record field ?

When an user edit a file it must be checked for proper input

When multiple fields are edited they may have a relationship on consistency 
and there is a mutual validation

When you save the recordset  there could be errors on writing and 
the whole transaction need to be discarded instead of being partly 
written.

validation is not a part of the UI yet, but it will be.

the idea is simply not to submit the data until the form is validated. 
I've not decided yet, but validation could be a reactor, the way 
things are shaping up right now.

P: Validation ('import) and Active Record (RoughCut) are essential 
components of QM.  Validation (along the lines of 'import) could 
easily be part of a panel/layout's specification...

Ok Henrik, please do not forget a "record modified" trigger for the 
UI. In multiuser enviromnent it is really useful to know if the record 
has been modified by someone else.

hmm.. yes, will see what can be done.

any new screenshots? :-)

Henrik - what was last status of resizing? Carl admitted, that resizing 
is broken. But I do remember some discussions about using different 
model to Carl's choosen one. And btw - is 'max-size requirement still 
there?

resizing has not changed yet. it's pretty isolated so we can choose 
to fix that if Carl doesn't get to fixing it. no real show stopper 
yet, other than it's annoying to look at.

screenshots: not really anything interesting. it's the same as before, 
only I'm working on how to error handle reactors. some reactors, 
I think, should be handled in a more friendly way than currently 
(simply crash).

So we can start using R3-GUI and expect minor changes to use and 
implimentation?


I thought there was going to be some major changes yet to come and 
present functionality might change significantly...

we change one thing at a time.

So if I follow the new docs i'm pretty safe?