World: r3wp

i think that carl need it for DevBase

until we have a odbc plugin. we need a good diskbased datastore in 
R3

If you look inside devbase you can see kind of DB there, but finally 
it should be a Module with methods, or Protocol with functions both 
simple and for general use IMHO.

It is not problem of ODBC you can have it today in Rebol 2, even 
better use SQLite or MySQL layer you have at hand, but SQL is not 
the only solution

a good demo In My Humble Opinion, will be a CRUD example application 
full R3

that take avantage of all greats features of R3

You can see frm discussion in this thread R3 need to be fixed first

From CRUD you have CRU nowadays

I've just been reading a little about something called Unobtrusive 
Javascript which aims to separate the behavior from the structure 
of html document.  


Doesn't VID suffer with the same problems where behavior is closely 
tied to the structure of the GUI?  And shouldn't we be looking at 
also solving this problem?

So  for instance from the wiki we have this

files: read %*.r

view/across [
    text-list files do [set-face ca read-string pick files value]
    ca: code-area
]

when maybe somet hing this is preferable

actions: [
	tl:.on-click [  [set-face ca read-string pick files value] ]
]

view/across [
    tl: text-list files 
    ca: code-area
]

ignore the double [[ ]]

Couldn't you do something like this, using compose?

actions: [

 my-text-list [set-face my-code-area read-string pick files value]
]

view compose/only [
	my-text-list: text-list files do (actions/my-text-list)
	my-code-area: code-area
]

And the same for every other possible event?

Sure ... but just looking at cleaner ways of doing this separation 
... getting rid of the 'do

It should be pretty easy to write a function that maps an ACTIONS 
block such as the following into a window:

	actions: [
		my-text-list [
			do [set-face ... ]
			"other-event" [ blah blah..]
		]
	]

where "other-event" could be on-click etc..

then the window doesn't have to specify any actions.

But I know what you're saying. You probably want such a function 
built in and used in the examples, so it becomes commonplace.

Yes

Maybe there could be a stylize type of way to deal with actions

Function name and arguments?
set-actions: func [window actions ...

anonymous windows?

I think it should be defined inside the window definition

set-actions view window-spec actions-block

(Assuming VIEW returns the newly created window object.)

modal windows??

(which it does.)

don't return until closed

AFAIK

Ok, so you want the window definition to separate internally into 
two parts.

Essentially:

view [
	; ACTIONS
	my-text-list/action: [set-face ...]

	; STRUCTURE
	my-text-list: text-list data files
]

yes just like a html page

(I'm still sort of using R2 terminology...)

and there's also passing the face correctly to the actions

Well, it should probably be in the reverse order, I suppose. Structure 
is put in place first, then behaviour operates on top of that.

view [
	; STRUCTURE
	my-text-list: text-list data files

	; ACTIONS
	my-text-list/action: [set-face ...]
]

makes it easier for the view layout engine I guess

STRUCTURE
 is actually "NAME-REFERENCE, STRUCTURE, CONTENT"

I'd also like to have it so that we don't have to name objects and 
can point to them based upon order ...

ahh... retract that.

I've spent some time thinking about that in the past, and it's difficult, 
if not impossible.

in case we wish to dynamically insert objects into the display and 
then remove them as they do in Javascript

yes, exactly. Dynamic structure.

Why?  If there's a tab order ... then there must be a serial structure

Which can be messed up all too easily by dynamic structure. Your 
program could reorder tabs for instance.

Or, as you say, a tab could be inserted/removed.

Eg.  I like to create tables first as instant feedback, and then 
fill them with data from an async function.

But I need to overlay a busy graphic which I can then remove ...

in the callback