World: r3wp
[!REBOL3-OLD1]
older newer | first last |
Claude 13-Feb-2009 [11316x2] | a good demo In My Humble Opinion, will be a CRUD example application full R3 |
that take avantage of all greats features of R3 | |
Pavel 13-Feb-2009 [11318x2] | You can see frm discussion in this thread R3 need to be fixed first |
From CRUD you have CRU nowadays | |
Graham 14-Feb-2009 [11320x4] | 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 [[ ]] | |
Anton 15-Feb-2009 [11324] | 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 ] |
Graham 15-Feb-2009 [11325x2] | And the same for every other possible event? |
Sure ... but just looking at cleaner ways of doing this separation ... getting rid of the 'do | |
Anton 15-Feb-2009 [11327x4] | 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. | |
Graham 15-Feb-2009 [11331x2] | Yes |
Maybe there could be a stylize type of way to deal with actions | |
Anton 15-Feb-2009 [11333] | Function name and arguments? set-actions: func [window actions ... |
Graham 15-Feb-2009 [11334x2] | anonymous windows? |
I think it should be defined inside the window definition | |
Anton 15-Feb-2009 [11336x2] | set-actions view window-spec actions-block |
(Assuming VIEW returns the newly created window object.) | |
Graham 15-Feb-2009 [11338] | modal windows?? |
Anton 15-Feb-2009 [11339] | (which it does.) |
Graham 15-Feb-2009 [11340x2] | don't return until closed |
AFAIK | |
Anton 15-Feb-2009 [11342x2] | 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 ] | |
Graham 15-Feb-2009 [11344] | yes just like a html page |
Anton 15-Feb-2009 [11345] | (I'm still sort of using R2 terminology...) |
Graham 15-Feb-2009 [11346] | and there's also passing the face correctly to the actions |
Anton 15-Feb-2009 [11347x2] | 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 ...] ] | |
Graham 15-Feb-2009 [11349] | makes it easier for the view layout engine I guess |
Anton 15-Feb-2009 [11350] | STRUCTURE is actually "NAME-REFERENCE, STRUCTURE, CONTENT" |
Graham 15-Feb-2009 [11351x2] | 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. | |
Anton 15-Feb-2009 [11353] | I've spent some time thinking about that in the past, and it's difficult, if not impossible. |
Graham 15-Feb-2009 [11354] | in case we wish to dynamically insert objects into the display and then remove them as they do in Javascript |
Anton 15-Feb-2009 [11355] | yes, exactly. Dynamic structure. |
Graham 15-Feb-2009 [11356] | Why? If there's a tab order ... then there must be a serial structure |
Anton 15-Feb-2009 [11357x2] | 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. | |
Graham 15-Feb-2009 [11359x3] | 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 | |
Anton 15-Feb-2009 [11362x3] | Ok, so you as the programmer know that your table has a specific, static order at the time you need to fill it. No problem. |
Did you also mean that you'd like ACTIONS associated with STRUCTURE elements anonymously? | |
view [ ; STRUCTURE text-list data files ; <---- element #1 code-area ; <---------- element #2 ; ACTIONS [on-click [set-face ...] ] ; <---- actions for element #1 [on-enter [ ... ] ] ; <---------- actions for element #2 ] | |
Graham 15-Feb-2009 [11365] | well, I don't want to name each element of the structure |
older newer | first last |