World: r3wp

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.

on-update is a different concept, which would be done using an ATTACH 
reactor. We still have to decide how this is going to be done. Carl 
did not like the first suggestion of adding a flow engine.

Henrik - is there any progress on more important GUI parts, like 
keyboard navigation, etc.? :-)

keyboard navigation is already there. we just lack a GOB to display 
which face is tabbed.

next will be to return to ATTACH and see how we can do this as simply 
as possible without getting a "no" from Carl.

Do we count for so called "accelerator" keys? I mean - in Windows, 
you can see underscorred letters, which you can use as a keyboard 
accelerator keys. But I can also imagine other aproach, e.g. that 
pressing Alt will display small boxes displaying accelerator keys. 
E.g. Lotus Notes does so. If there will be layers introduced, it 
could be rather easy to have such visual markers (ditto for mouse-over 
help)

I noticed this under Experimental in face-reactors.r3:


signal: ["Send a signal to another face." id [word! integer!] who 
[word! none!]] [
	unless who [face: parent-face? face]
	do-style face 'on-signal id
]

Pekr, that might be possible to do. An interesting issue is how to 
write up accelerator keys in a simple way. I'm considering a small 
dialect: [alt ctrl d] or something.

I guess my bias is that the burden of what input goes where is on 
the data/application model. To give the UI that responsibility would 
seem unnecessarily complex (that's not to say it wouldn't be favourable 
to some applications, but this is core design, right?). I'd find 
it more useful to have the UI have an independent data model where 
I could extract some data to send one (or more) place, extract other 
data to save another, and so on.


I find that's what I miss when working with R2 VID, not so much that 
it doesn't bind to data sources...

Off the topic.

One off the things I added to my events  handler is the propagation 
of the events (from the inner to the outer face).
Like in R2

It's so much handy when styles have sub-faces (allowing generic actors).
Henrik, don't you have the same need ?

I'm not sure what's meant by generic actors? I haven't investigated 
whether we can do that now or how it would be used.

ok, an example.
You make a button style with subfaces.

But the click event must be throwed to the container independantly 
of which sub-faces received it at first

I'm not sure why I would want the subfaces to be receiving the event, 
if the container face is supposed to act as the button? I would perform 
the action on the container face.

But I think this is fully possible, if you need it.

But actually, the event will not be sent to the container if you 
move your pointer over a sub-face

if you don't povide it in the event-handler, I meant

If I need to communicate with the container, I usually just: do-style 
parent-face? face actor-name

I was just wondering why you don't need it, actually :)

well, ok it will work, but  in your case, the child faces must be 
well aware of the need to redirect some events to the parent.
In my model, they don't need to know it.

The container "capture" the events he needs

ok, we'll just have to see if this becomes necessary later. the model 
I base containers on is a little different.

right now I have some trouble getting the new record reactor to work....

:)

Chris, you are somewhat right. At least there are some parts of GET-PANEL 
and GET-FACE I've not paid enough attention to. The thing for the 
prototype is that it collects data from faces and puts them in an 
object in kind of a convoluted way.

What about the following design for GET-FACE:

- When used on a panel, GET-FACE returns a flat object

- If a face doesn't have a set-word name, then it's not included 
in the object


And for SET-FACE, it would have to be directly opposite, so you can 
say:

set-face get-face panel

I think that'd be good step forward, and quite intuitive...

And if possible, the top-level layout object...

This http://www.rebol.net/wiki/Template:GUI_TOC leads to this http://www.rebol.com/r3/docs/gui/gui.html
and this message


So, you found this page from the sitemap? Sneaky.

This GUI section 
is under construction (on a different server). It's not meant for 
publication yet. To be transferred here as they move into final draft 
stage.

Many of these links don't yet exist. They are being filled 
in at this time. Also, the image links are not yet setup.

So, no I didn't.

Are scripts like Jawi script supported?

Guess right to left is not

Chris, the top level layout object is the window and it should be 
possible to get that too, but by using GET-PANEL directly. GET-FACE 
on the WINDOW style returns a value that would be stored by clicking 
an ok or cancel button in the window.

...but the value is not yet stored as the ok and cancel button styles 
don't yet exist.

Looking at reactors now, this seems to be the way to store these 
emit functions. Reactors are more powerful than I thought and according 
to docs, under the place Graham links to above, we can write our 
own. The MAKE-REACTOR function doesn't exist though, it's called 
MAKE-FACE-ACTIONS.


I hope to make use of triggers as well. Triggers are faces that are 
not stored in the layout after they have been processed. They are 
performed either when entering a panel during layour or when exiting 
it (possibly also other places). I hope that triggers can be used 
to pass specific options to already laid out faces, making triggers 
appear as options to a face.