World: r3wp

The question is: How to get from GUI to a DB and back without cluttering 
the VID code, or having to code to much. The idea is to collect the 
GUI elements belonging to one record and than auto-create tables 
and columns. So, people can concentrate on the app code and get the 
75% always necessary database code for free.

If you have any ideas, hints let us know.


We have a first prototype running, but we want to make it more elegant.

Well, if you show us something it will be easier to propose ideas.
I'm working on my own GUI aswell currently :)

My main idea (Already tried in the past ) is to build enough small 
primitives to allow to constuct all the standard styles without the 
need to add bloated hand written code.

The primitives are context sensitives, meaning that blocks of primitives 
can be shared between several face without the need to bind/copy 
them for each face.

The way that accessors on panels work in R2 is a good start (almost):

	>> lay: layout [pan: panel [foo: field "Foo" bar: field "Bar"]]
	>> set-face pan ["Bar" "Foo"]
	>> get-face foo
	== "Bar"
	>> get-face pan
	== [foo: "Foobar" bar: "Barfoo"]

Tie that to validation, eg:

	import get-face pan [foo: string! [some char] bar: opt string!]

Or an active record:

	record/update get-face pan

Not perfect as is, and perhaps simplistic, but I could imagine finding 
a way to add more semantic hooks to a layout and have a somewhat 
automated way to set/retrieve data from parts or all of the gui...

Especially recognising that the layout structure may not represent 
the application data structures.  I've toyed with the idea of a 'ref 
keyword - ui: layout [field ref 'user/name] - ui/get 'user/name, 
ui/set 'user/name, ui/get 'user == [name ...]

i think the syntax of the data block to get/set the GUI and get/set 
the DB should be the same.
>>get-face pan
== [foo: "foo" bar: "bar"]
>>set-face pan [foo: "bar" bar: "foo" ]

>> get-db [foo: "bar" bar: "foo"]

== [foo: "bar" bar: "babar"]   ;the DB can decipher the data block 
and knows well what is the requested key and what is only attribute.

>>set-db [foo: "foofoo" bar: "..."] ; update the record or create 
a new one.


Having exactling the same syntax allow to pass data between the GUI 
and the DB without pain.

specs:

http://rebol.net/wiki/R3_GUI_Specs#Field_Persistence

Steeve: any reason why set-words over words?

Hmm... Ok

Henik, I'm not sure of the interest to add record specifications 
on each field. a simple record tied with the panel should be enough.

E.g with your example:

 name-panel: group 2 [
   label "ID"   id: field 
   label "Name"   name: field
   label "Address" address: field 
   label "Post Code"  postcode: field 
   label "Comment" comment: area 

 ] record name-table [name: key Address:  postocode: comment: data]

Chris, what do you mean ?

In your examples you use set-words...

Ah, ok.

It's because it's easy to convert them into objects. Don't know if 
it would be usefull or not.

Henrik: Do you also tie validation and multiple data sources to each 
binding?  I kind of like the independence of a data model co-existing 
with a layout structure, you can poke and prod data from outside 
while the view internals just get on with what they do...

Steeve, the purpose is allowing different scoping per field. According 
to Robert, he sometimes needs to use a field from a different table. 
Of course it would have to be possible to cover what you need with 
the outmost panel and then having fields inside it be covered by 
what the parent record specification gives.

Chris, in principle, each field could be tied to separate data sources.

group 1 [
	value1: field record [table1] ; would use value 1 in table 1
	value2: field record [table2] ; would use value 2 in table 2
	value3: field ; would use value 3 in table 3
] record [table3]

Henrik i see, but there should be the less possible specifications 
of the DB inside the styles themself.


Each panel should only (see) a flat VIEW of its tied tables (more 
easy to manage). 

Then each VIEW (like in SQL) could have a shema specification (somewhere 
else in the code) which desrcibes all the referential constraints 
between tables of the DB.

Just an idea.

A bare-bones version would be something like:

group 1 [
	value1: field
	value2: field
	value3: field
] record [table1]


which could serve most needs. Wouldn't that be the same as tying 
fields directly to a flat table?

Chris, the storage would require a "save to table" action. It wouldn't 
save as soon as you tab out of the field, so validation is fully 
possible.

On WAIT:

  loop 1000000 [wait 0.01]

Should not consume 100% should it? It does here, on Windows.

Something more to consider...

dynamic: group 1 [field field field] record [table1]


For when you want to set up fields where you know the order, and 
really want to minimize the layout code.


The outer panel would be set up with an ON-EMIT actor that traverses 
the inner faces. We already have this in the prototype, so maybe 
we can map the traverse order to the table columns.

It may not be a great idea. There are some possiblitiies for screwing 
the emit process up.

Do you Guys use REDUCE/ONLY ?

Gregg, time to curecode it, I suppose. I get the same here.

About the earlier mention of GET-FACE and SET-FACE, these are considered 
basic accessors to manipulate the fields and gather data from them. 
These aren't going away. The use of ON-EMIT specifies directly to 
use GET-FACE to obtain data from the face, so it's not some kind 
of "special accessor" that somehow replaces GET-FACE. The job of 
ON-EMIT is to copy the data, formally obtained from the field to 
the database record cell.

We'll be building another prototype. The current one works against 
SQLite, but the next one should be built so that we can demonstrate 
that the layout shouldn't care about which db it's connected to, 
so we'll also make a flat file database version.

are you trying to suggest, that get-face/set-face are getting only 
one parameter? I thought it changed in comparison to VID2?

It hought the syntax now is - get-face 'face 'attribute

that's get-facet, not get-face.

ah, sorry ...

isn't it too early to think about higher abstraction layers? You 
are talking forms, DB connections, etc. But maybe not, dunno ...

dunno how others do it, but here's one maybe interesting product 
- http://sqlrelay.sourceforge.net/

no, the point is that this will be part of the main layout dialect, 
so it's important to consider now.

And one note of unexperienced coder (me) :-) - when I tried to look 
into that RoR db system, it reminded me of DOS app generator tools 
I used for Clipper language. While it was cool, it was also kind 
of limited. I mean - it always end like - if you need something more 
fancy, you have to use raw aproach. And it introduced unnecessary 
layer, which you had to learn, and which was not able to provide 
you with general enough functionality for 100% cases. This is just 
a note to keep it in mind, nothing more - simply to not introduce 
another layer, if we are not sure, it will be usable for 90% of cases 
and has some benefits ...

so - it is supposed to be part of VID dialect?

design is not finalized, but yes, the extension is a single actor, 
ON-EMIT (there might be more), a single reactor, RECORD and that's 
it.

well, the concept is not clean anyway, just dunno. We have get-face, 
set-face. For me, panel is a face too, it just contain subfaces. 
I really don't know, why panels are treated in specific way - we 
already got get-panel, set-panel, clear-panel.

In DOS era, when I coded in Clipper, MS Fox Pro introduced so called 
"scatter", "gather". Every language (Clipper, Visual Objects, Delphi) 
then copied naming and the principle ... to get and set values from 
form ...

this doesn't have anything to do with those functions. :-) if you 
didn't have an actor to handle things like EMIT, you would have to 
write special db handling code up against GET-FACE and do a lot of 
silly wiring, like is necessary with VID.

I just don't understand the purpose. Can you give me short VID level 
code idea?

just posted it above. see the "bare bones" example.

hmm, I am not sure I like it. I might agree with Chris, that those 
things might turn into being so variable, that you might not easily 
find the correct implementation.

Once again - app generator I used, allowed to specify on-insert (new 
record), on-edit, on-update actors ....

dunno how to get it into dialect, but you need all of those. And 
I forgot ... validate

this really is about as minimal as it can get with the layout dialect. 
validation would be another reactor.

I think it will improve with the next prototype. then it will be 
clearer what's going on inside ON-EMIT.

for e.g. on-update was usefull ... when user updated the field ... 
it could cause setting/updating another field. The method was so 
advanced, that if you deleted the record via the API, it caused DB 
updates, so e.g. if you accepted something on-stock, then deleted 
it, it was withdrawen automatically.