World: r3wp

Well, why are Unobtrusive Javascript people doing it ?

For quick little layouts we can see that the separation, with all 
those extra nested brackets and interpretation requires extra effort. 
But for large, complex layouts, the separation must have some benefit.

(<--- insert benefit here..)

I have lots of complex layouts ... so I think it will help.

Only way to find out is to test it though.

I think it makes things harder, at least for a short while. After 
that I cannot see...

The reason is that there is an extra name reference needed to associate 
the action to its element, because they are now separated. In large 
layouts, the separation of structure and behaviour puts these closely 
related aspects further apart, so it means more scrolling.

Except that the structure is now much smaller without all the behavior 
code mixed in .. so it's less scrolling :)

That's true, if you *just* want to look at structure.

But what makes "structure" an aspect that deserves such attention 
? It's still not clear to me.

http://en.wikipedia.org/wiki/Unobtrusive_Javascript

I think other aspects of a program could be more important, at other 
times, or simply at different places in the code. :-/

The unobtrusive solution is to register the necessary event handlers 
programmatically, rather than inline. 

so, say you had a number of text-lists that all had the same event 
handler, you just define it once instead of 3 times

where number = 3

for simple windows there is no gain.

It's only for large complex windows where the gains are seen.

Ah, that's why you mentioned stylize.

It's a form of code factoring.

It should be easy in rebol to define actions programmatically, or 
to make your own style of text-list before-hand.

why not make it automated by default?

Well.. why not?

I note the Unobtrusive Javascript wikipedia article example sets 
up the "hundreds of .. date fields" with the same action. (Of course 
I understand they could be subtly different, determined programmatically, 
but still..)

This could be done in rebol better using stylize-like functionality.

I think we don't really have the problem that's being solved in that 
article example.

inline syntax prevents the registration of more than one event handler 
for the element's onchange event

 - we don't have this problem in rebol. It looks like they are working 
 around a problem in html inline javascript specification.

I still like the cleaner separation of gui from function

Well, I think it can pretty easily be done for your own forms, by 
making a function that accepts an action specification, as above. 
Apply it to your forms and that's that. Eg. if you could say:

	window: layout [ ...text-list ... ]
	set-behaviours window [ text-list [...] ]
	view window


Wouldn't that be almost as good (if not better) than any built-in 
inline action specification ?

(such as we explored above.)

You just need to write the set-behaviours function :)

:)

Must go - exercise time.

I think that your talk here is a little bit late for VID3, as it 
seems to me (according to docs), that those things were already decided 
...

As for actions (actors, reactors), having them separate from style 
structure? I can find it confusing ...

There is not just general 'do, like in R2, there is now many reactors. 
In order to better understand new architecture, here's some docs 
- http://www.rebol.net/wiki/R3_GUI...

Actions separation is done in stylize level ...

I  don't think it's too late ... noting is set in stone yet.

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.