World: r3wp

Hmm, I don't understand advantage to what you propose anyway ...

I am sorry for my extreme oppinion on this subject but I think "unobtrusive 
javascript" was invented when web2.0 got hip and cool and when web 
designers started coding. To me as a user it meant that basecamp 
blocked my whole browser (even the mouse pointer didn't move) on 
every page reload for 1-2 seconds (while js was attaching events 
to all the nodes).

gmail / google calendar were the apps that pushed the edge of what 
client with js+html can do and look how unobtrusive are they

J: I'm not sure that's fair - UJS addresses many problems faced confronting 
a very complex development environment to perform even elementary 
manipulation (see also Progressive Enhancement/Graceful Degradation). 
 At that, the three sites you cite are neither examples of UJS or 
PE/GD, nor typical examples of usage.

Not usage, need.

For another place, perhaps, but designers need to know how to code 
(web 2.0 or no).  If they leave all coding to programmers, design 
gets messed up.

No problem , I said I have a little exptreme oppinion on this, and 
extreme opninons are usually not correct ;) . But I think "unobtrusive 
javascript" is an extreme option too, I believe that eingeeners have 
to find fastest, cheapest, most robust and mainainable solutions 
that *work the best* for their problem. But something like UJS is 
a label or an ideal that you can hold to in your work and more you 
hold to it better you are from this ideal's viewpoint, but I like 
to be more flexible. I will adhere to it or only so far as I think 
it get the best coctail from the 5 points I mentioned above.

basically no problem if we have different view of this, I just wanted 
to note my vote that not every web-developer thinks UJS is such an 
awesome idea by itself. That doesn't mean I want to do "big grey 
ball of goo" programming either.

I think the web is a special case though.  I don't think there is 
any other environment where language interpretation varies so widely, 
and where binding the language can have harmful effects.  Yes, heady 
concepts are not always pragmatic, but the short road to pragmatism 
on the web is fraught with pitfalls.

big grey ball of goo
 - is that Perl?

G&A: I'd like separation too - in the long run, it makes for code 
that is easier to adapt and maintain, and allows you to refine language 
around the individual components

First, I think JS is not something we should look at for models. 
It's new enought that it is just going to reinvent what's been done 
before, unless they come up with something truly revolutionary, and 
my gut feeling says that's not going to happen. It also depends on 
what kind of apps you're writing, and what you want the language 
to hide from you.


What's been done before that works, or not?  MVC has seen a resurgence 
with RoR and other frameworks being built on it. 


Now look at a low level approach, where you handle the main event 
loop yourself. Anyone remember writing C programs for Windows early 
on? Maybe some still do. You had a huge switch statement to dispatch. 
On the downside, that was hideous to read and maintain. A benefit, 
though, was that you could hook into it very easily, because it wasn't 
spread throughout the app.

Then there's the whole VB/event-driven model.


R2+VID is wonderful for very simple things, because you don't have 
much to do, actions are right there with their faces, etc. It starts 
getting in the way when you build larger apps that need to track 
relationships between faces and such. And it is not well-suited to 
large apps, just like REBOL itself. It doesn't provide the organization, 
tools, and features needed. Of course, we can build all that ourselves, 
if we have the inclination. RebGUI is the best example of that.

I like the idea of apps based on FSMs and message dispatch. That 
means simple apps aren't nearly as simple anymore, but it gives you 
the tools to build bigger things. It's also a different way of thinking, 
which can be hard to get people to accept. 


Anyway, rather than asking if UJS is the right model, we first need 
to ask what our goals are.

Unobtrusive Javascript

 is based on the principle that the behaviors attached to the structure 
 need to be optional, because Javascript might not work or be turned 
 off. This will *never* be the case for R3 GUI behaviors, so the principle 
 doesn't apply here.

The "separation of form and function" principle has already been 
implemented with the separate style system.

But that is not the "Unobtrusive Javascript" metaphor, it is more 
like the separation of HTML and CSS.

If you have a one screen application, it doesn't matter how you write 
it.  If you have over 300 screens as I do, then you look at ways 
it might be more easily maintained.

Gregg, JS is a few years older than REBOL.

We have. That is why we have the current design.

BrianH, how does R3 styles work?  I didn't notice it on the R3_Gui 
page

Remember, the layout won't have style code in it.

(sorry, your message hadn't come through yet)

R3 styles?

(sorry, I was busy). Imagine if you took the structure/appearance 
separation of HTML/CSS to the extreme, and had *no* appearance code 
in your layouts, just behavior and structure. Put all appearance 
code in the styles. That's the R3 GUI. Oh, and the styles will be 
themable too.

got an example?

the one I took from the wiki has the behavior code attached to the 
structural elements

Not really, ask Henrik. I'm a Core guy.

Behavior and structure are together in the layout, yes, but in a 
way that is easily seperable. And that doesn't matter because the 
layout won't have appearance code in it.

Can we style behaviours as we can structure?

( I keep switching between UK and US spellings ... )

I don't get the question. You can seperate the actual implementation 
of behavior from the layout easily. You can't style structure.

You style styles (what other GUI systems call controls).

The panel system let's you swap in different pages if you have more 
complex apps - see the demo code.

It will be much easier to build 300-screen apps. :)

I can provide an example:

view [
	panel [
		error-text "Something went bad"
	]
	group [ok-button cancel-button]
]

There's no appearance code in this layout.

You can do the same in VID for R2.

But it's *much* harder :(

Well, I've done that in my own VID extension kit (which I'm still 
contemplating whether I will release some day): Provide more styles 
with very specific purposes. This strongly reduces the need to be 
specific many times all over a layout and the layout becomes much 
smaller and cleaner. Also avoiding stylize inside the layout helps.

we have close buttons, and ok buttons etc.  Can we define them on 
the fly for the scope of the window?

again this also comes from the concept of styles that are described 
by purpose rather than appearance, so you don't want a red or blue 
button, but an ok or close button.

and if you want both?

VID3.4 will allow that.

What's the code name now for R3's gUi?

was it ever decided upon?

You can define the button actions as you please. If you look at this 
shot:

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

The 5 colored buttons are separate styles, based on BUTTON.

I just call it VID3.4.

No decision yet. I call it R3 GUI.

Note that I was against users setting colors. This makes it much 
harder to build good styles.

It's so tempting to set colors and styles directly in the layout, 
because it's quick to prototype with, like in R2 VID, but once your 
layouts grow, you really want to get rid of those appearance decisions.

Yeah, it is much better to set names of semantic attributes that 
have associated colors in the theme, then let the theme pick the 
actual color that fits with the rest.