RBC Coloring .. the dynamic version ...

Works just fine most of the time, but then it will start
delaying the colouring.  Usually when I accept a change to a method.
It might leave the method black for 5, 10, 15 seconds.  I can look at other
methods too and they are black until it finally decides to colour things
again.

Anyone else seen things like this?

--
Dennis Smith                         +1 416.798.7948
Cherniak Software Development Corporation   Fax: +1 416.798.0948
509-2001 Sheppard Avenue East        [hidden email]
Toronto, ON M2J 4Z8              sip:[hidden email]
Canada         http://www.CherniakSoftware.com
Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP

Never mind -- my fault.
I had added an invocation of "Smallint" to check for cases of
bad boolean expressions
    a = b | c = d
at every code compilation.  I had
    SmallintContext new
which takes a few seconds to build internal stuff.  I now just create
and keep one of them -- fixed the problem!

Dennis Smith wrote:
> Works just fine most of the time, but then it will start
> delaying the colouring.  Usually when I accept a change to a method.
> It might leave the method black for 5, 10, 15 seconds.  I can look at
> other
> methods too and they are black until it finally decides to colour
> things again.
>
> Anyone else seen things like this?
>

--
Dennis Smith                         +1 416.798.7948
Cherniak Software Development Corporation   Fax: +1 416.798.0948
509-2001 Sheppard Avenue East        [hidden email]
Toronto, ON M2J 4Z8              sip:[hidden email]
Canada         http://www.CherniakSoftware.com
Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP

James Robertson has just put up a call on his blog for feedback on what
you, as customers, want to see Cincom doing with Seaside.

What do you want?
What do you need?
What do you expect from us?

If you have ideas, the sooner you can back to us the better, we're doing
our initial planning shortly. So throw up your burning issues.

Either reply to this thread, email me directly or if you want to be
clandestine, email jarober at gmail dot com

Cheers,
Michael

Hi,

1) I hope, as has been request on another thread, that focusing on Seaside will not means losing focus on UI builder, better UI, compositional graphics, interfacing to DLL, etc
2)Regarding to Seaside, full support is welcomed, but the first thing not to forget is, in my opinion, that Seaside is an open source project, so every general modification should pay attention to the community and should be shared with the community. Otherwise we can have a bad feedback from the people working on it from log time, and the positive feeling can become a negative one. I would not like to have a VW specific version of Seaside different and incompatible with all of the others.

ciao

Giorgio

> James Robertson has just put up a call on his blog for feedback on what
> you, as customers, want to see Cincom doing with Seaside.
>
> What do you want?
> What do you need?
> What do you expect from us?

I'm eager to begin doing something with SeasideAsync and/or Scriptaculous.
Would either of these fall under Cincom's Seaside umbrella?  So far I've
been unable to have an aha! moment with them.  It would be great if there
were good documentation that makes this stuff easy to figure out.

-Carl Gundel
http://www.runbasic.com 

Carl Gundel wrote: All things seaside are on my radar. Whether they get prioritised or not
remains to be seen. In the case of ajax and comet technologies I'll be
pushing those as a reasonable priority. They boost the usefulness of
Seaside considerably.

Hi carl

but why don't use the packages made by lukas that are based on  
scriptaculous.

Stef
On 21 juin 07, at 06:01, Carl Gundel wrote:

> Hi carl
>
> but why don't use the packages made by lukas that are based on  
> scriptaculous.

Which packages are these?

-Carl Gundel, author of Liberty BASIC
http://www.libertybasic.com

SeasideScriptaculous and SeasideAsync in Public Repository,

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

SeasideScriptaculous and SeasideAsync are also shipped as parcels.
See in contributed/Seaside

HTH
Michel.

Oh, of course I am aware of those packages and I have tried them.  :-)
Sorry I guess I wasn't clear.  My problem is with understanding well how to
use those packages, so I was asking for better instructional documentation.

-Carl Gundel, author of Liberty BASIC
http://www.libertybasic.com
----- Original Message -----
From: "Boris Popov" <[hidden email]>
To: "Carl Gundel" <[hidden email]>; "VWNC, " <[hidden email]>;
<[hidden email]>
Sent: Thursday, June 21, 2007 10:41 AM
Subject: RE: Seaside for VisualWorks


SeasideScriptaculous and SeasideAsync in Public Repository,

Cheers!

-Boris

OK, I have a question about seaside ...

Why does everyone seem to love seaside -- it seems to me it has two
drawbacks, but are in fact
its formost features
    1. when we display a page, we can (I believe?) wait for a "return"
from the display of the page.
          This means that every web page is like a modal dialog???  With
a GUI, we display the thing,
          then carry on or go away until the user hits something which
invokes a method and does something,
          and then goes away again etc etc.  Doesn't the seaside
mechanism take us back to some time before event driven
          GUI systems?
    2. we code the web page in Smalltalk.  In VW I have the ability to
code a GUI in smalltalk, but mostly I don't,
          I use a GUI painter.  Why don't I use a painter to build my
web page which in turn (using tags) calls back to
          my domain in an event driven manner like a GUI.

So -- I am curious???


Michael Lucas-Smith wrote:
--
Dennis Smith                         +1 416.798.7948
Cherniak Software Development Corporation   Fax: +1 416.798.0948
509-2001 Sheppard Avenue East        [hidden email]
Toronto, ON M2J 4Z8              sip:[hidden email]
Canada         http://www.CherniakSoftware.com
Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP

1. Seaside is callback-based, but indeed relies on server side cache of
continuations to save your flow through the application; there are many
arguments for and against which I'm not going to get involved in right
now, but as a matter of personal preference I can say the benefits
outweigh the drawbacks by a very wide margin

2. It's a little like comparing apples to oranges, because web interface
has content element (XHMLT) separate from the look element (CSS), so in
fact when you're "building" UIs, you are not laying them out just as you
would lay out widgets. Rather you create a logical/semantic structure
which then gets interpreted with help of CSS into a full user experience

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.
With them.

It sounds like you're coming at this from the angle of someone who has
never suffered the horror of vignette, jsp's, asp's, php, cold fusion,
plain html editing with/without a html editor.

In many respects the answer to your question is this: Seaside catches us
back up with the gui's core capabilities - connecting the screen to the
domain. The next step beyond that would be to make a ui builder for it -
some people are doing that.

It turns out that what we desire the most in web applications is
granular composition. You don't really get that by breaking your program
up in to hundreds of small html files and pasting them together with
application code that links back to another page which interprets the
form data and calls your domain code to then do the whole thing over
again. So Seaside encapsulates that pattern for you. Call/Return is more
like going from an edit window, to picking a search button on a field to
find a person to drop in to the 'seller' box.

Granular composition of pages and behaviour is always best done as close
to the domain as possible - so naturally smalltalk fits in like a charm.
If you don't subscribe to the whole DSL thing, then yes, templated HTML
with tags in it is the way to go for you.. ala Ruby on Rails. However,
I'd wager the productivity of a seaside developer is significantly
higher than that of a rails developer once you get past the initial CRUD
screens.

To put the problem another way - imagine having a GUI framework that
didn't have callbacks, that you had to define the screen with an id and
the model with an id and you got a bunch of field changes in bulk when
the user hits 'save'. It'd be rather awkward programming. The lack of
events is significant enough that you'd just plain give up.

So why didn't people give up? .. well this browser thing was already on
every microsoft windows computer and it gave you a workable
client-server model. More recently, with some smart Javascript
libraries, we've managed to get back callbacks, events, per-field
updating and validating.. all the things we expect from a GUI framework.

But now we have all these fiddle 'things' we have to do to each and
event field or form or label just to make it do what we want. Naturally,
the answer here is to employ a more powerful templating system - so
powerful it may as well be a programming language.

<label for="i3838" class="mandatory error" title="Mandatory field"><img
src="error.gif" alt="Mandatory field"/><a
name="name"/>Name:</label><input type="text" name="name" id="i3838"
class="mandatory error input template" value="Full name"
onfocus="this.value == ''; this.removeClass('template');" onblur="if
(this.value == '') { this.addClass('template'). this.value = 'Full
name'; }" onchange="ajaxUpdate(this);"/>

Or.. I could write:

self addLabel: 'Name' isMandatory: true inputTemplate: 'Full name'
object: myObject aspect: #name.

Which would you rather call? The intricate mess of XHTML, CSS and
Javascript makes templating pretty much impossible now. Higher level
DSLs are needed to more accurately describe the user interface.

So, in the long response, it seems my answer is, Seaside makes some
things that are impossible - possible and makes some things that are
repetitive, error prone or just plain hard - easy.

Cheers,
Michael

Dennis Smith wrote:

It sounds like you're coming at this from the angle of someone who has
never suffered the horror of vignette, jsp's, asp's, php, cold fusion,
plain html editing with/without a html editor.

In many respects the answer to your question is this: Seaside catches us
back up with the gui's core capabilities - connecting the screen to the
domain. The next step beyond that would be to make a ui builder for it -
some people are doing that.

It turns out that what we desire the most in web applications is
granular composition. You don't really get that by breaking your program
up in to hundreds of small html files and pasting them together with
application code that links back to another page which interprets the
form data and calls your domain code to then do the whole thing over
again. So Seaside encapsulates that pattern for you. Call/Return is more
like going from an edit window, to picking a search button on a field to
find a person to drop in to the 'seller' box.

Granular composition of pages and behaviour is always best done as close
to the domain as possible - so naturally smalltalk fits in like a charm.
If you don't subscribe to the whole DSL thing, then yes, templated HTML
with tags in it is the way to go for you.. ala Ruby on Rails. However,
I'd wager the productivity of a seaside developer is significantly
higher than that of a rails developer once you get past the initial CRUD
screens.

To put the problem another way - imagine having a GUI framework that
didn't have callbacks, that you had to define the screen with an id and
the model with an id and you got a bunch of field changes in bulk when
the user hits 'save'. It'd be rather awkward programming. The lack of
events is significant enough that you'd just plain give up.

So why didn't people give up? .. well this browser thing was already on
every microsoft windows computer and it gave you a workable
client-server model. More recently, with some smart Javascript
libraries, we've managed to get back callbacks, events, per-field
updating and validating.. all the things we expect from a GUI framework.

But now we have all these fiddle 'things' we have to do to each and
event field or form or label just to make it do what we want. Naturally,
the answer here is to employ a more powerful templating system - so
powerful it may as well be a programming language.

<label for="i3838" class="mandatory error" title="Mandatory field"><img
src="error.gif" alt="Mandatory field"/><a
name="name"/>Name:</label><input type="text" name="name" id="i3838"
class="mandatory error input template" value="Full name"
onfocus="this.value == ''; this.removeClass('template');" onblur="if
(this.value == '') { this.addClass('template'). this.value = 'Full
name'; }" onchange="ajaxUpdate(this);"/>

Or.. I could write:

self addLabel: 'Name' isMandatory: true inputTemplate: 'Full name'
object: myObject aspect: #name.

Which would you rather call? The intricate mess of XHTML, CSS and
Javascript makes templating pretty much impossible now. Higher level
DSLs are needed to more accurately describe the user interface.

So, in the long response, it seems my answer is, Seaside makes some
things that are impossible - possible and makes some things that are
repetitive, error prone or just plain hard - easy.

Cheers,
Michael

Dennis Smith wrote:

OK, I will reply here to both you and michael.  I guess I don't disagree
in total.  We built our system
before seaside -- perhaps that is the issue at this point.

We already had a domain with the ability to build and connect GUI's to
it -- our framework to deal with that
is quite extensive -- so we build on top of it.  We build using tags, so
we can say

    <cg:field name=surname  />

This is sufficient to put up something like
       Surname  ____________
the label comes from the domain which knows that the user calls
"surname" -- other things can come
from that information too, default width, read-only etc etc.    We
output css information too, and can add to it
with a simple  xxx="abc" (xxx can be class, or div).  So the css already
has something to deal with.
A simple web page might look like

    <cg:field name="surname" />
    <cg:field name="firstName" />
    <cg:submit label="Add" action="addNew" />
    <cg:submit label="Update" action="updateEisting" />

this then appears much like our GUI's except we don't have a nice
painter for it.

I can see some advantages to seaside -- and I would certainly have
looked closely had it existed
at the time.  We build ous right after the tag support came out of cincom.

Thanks for the replies though -- I will keep them for reference, and
will keep an open mind.  Things like
ajax support might well make me take another look.



Boris Popov wrote:
--
Dennis Smith                         +1 416.798.7948
Cherniak Software Development Corporation   Fax: +1 416.798.0948
509-2001 Sheppard Avenue East        [hidden email]
Toronto, ON M2J 4Z8              sip:[hidden email]
Canada         http://www.CherniakSoftware.com
Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP

Also,

Templating = copy/replace
Seaside = refactor/rewrite

Somehow I suspect most Smalltalkers would pick the latter...

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.
us
> back up with the gui's core capabilities - connecting the screen to
the
> domain. The next step beyond that would be to make a ui builder for it
-
> some people are doing that.
>
> It turns out that what we desire the most in web applications is
> granular composition. You don't really get that by breaking your
program
> up in to hundreds of small html files and pasting them together with
> application code that links back to another page which interprets the
> form data and calls your domain code to then do the whole thing over
> again. So Seaside encapsulates that pattern for you. Call/Return is
more
> like going from an edit window, to picking a search button on a field
to
> find a person to drop in to the 'seller' box.
>
> Granular composition of pages and behaviour is always best done as
close
> to the domain as possible - so naturally smalltalk fits in like a
charm.
> If you don't subscribe to the whole DSL thing, then yes, templated
HTML
> with tags in it is the way to go for you.. ala Ruby on Rails. However,
> I'd wager the productivity of a seaside developer is significantly
> higher than that of a rails developer once you get past the initial
CRUD
> screens.
>
> To put the problem another way - imagine having a GUI framework that
> didn't have callbacks, that you had to define the screen with an id
and
> the model with an id and you got a bunch of field changes in bulk when
> the user hits 'save'. It'd be rather awkward programming. The lack of
> events is significant enough that you'd just plain give up.
>
> So why didn't people give up? .. well this browser thing was already
on
> every microsoft windows computer and it gave you a workable
> client-server model. More recently, with some smart Javascript
> libraries, we've managed to get back callbacks, events, per-field
> updating and validating.. all the things we expect from a GUI
framework.
>
> But now we have all these fiddle 'things' we have to do to each and
> event field or form or label just to make it do what we want.
Naturally,
> the answer here is to employ a more powerful templating system - so
> powerful it may as well be a programming language.
>
> <label for="i3838" class="mandatory error" title="Mandatory
field"><img "return"
> > from the display of the page.
> >          This means that every web page is like a modal dialog???
> > With a GUI, we display the thing,
> >          then carry on or go away until the user hits something
which
> > invokes a method and does something,
> >          and then goes away again etc etc.  Doesn't the seaside
> > mechanism take us back to some time before event driven
> >          GUI systems?
> >    2. we code the web page in Smalltalk.  In VW I have the ability
to on makes
> >>> this stuff easy to figure out.
> >> All things seaside are on my radar. Whether they get prioritised or
> >> not remains to be seen. In the case of ajax and comet technologies
> >> I'll be pushing those as a reasonable priority. They boost the
> >> usefulness of Seaside considerably.
> >>
> >
>

At 01:13 AM 6/22/2007, Carl Gundel wrote:
>Oh, of course I am aware of those packages and I have tried
>them.  :-) Sorry I guess I wasn't clear.  My problem is with
>understanding well how to use those packages, so I was asking for
>better instructional documentation.

This is a good example of what others on this thread are talking
about when they ask for more documentation.

Neither SeasideScriptaculous nor SeasideAsync have adequate package
comments, and most of the classes in these packages have no comments.

So, there's really no way to load these and get started using them
without looking somewhere else to try and figure them out, or to
begin reading code, which is not a viable way to get started with a
package of this complexity.

While I agree with Carl, I would add that adequate architectural
documentation is also needed, and this means complete package and
class comments.

M

(Repost, as I (michael) don't think it got to vwnc list)

It sounds like you're coming at this from the angle of someone who has
never suffered the horror of vignette, jsp's, asp's, php, cold fusion,
plain html editing with/without a html editor.

In many respects the answer to your question is this: Seaside catches us
back up with the gui's core capabilities - connecting the screen to the
domain. The next step beyond that would be to make a ui builder for it -
some people are doing that.

It turns out that what we desire the most in web applications is
granular composition. You don't really get that by breaking your program
up in to hundreds of small html files and pasting them together with
application code that links back to another page which interprets the
form data and calls your domain code to then do the whole thing over
again. So Seaside encapsulates that pattern for you. Call/Return is more
like going from an edit window, to picking a search button on a field to
find a person to drop in to the 'seller' box.

Granular composition of pages and behaviour is always best done as close
to the domain as possible - so naturally smalltalk fits in like a charm.
If you don't subscribe to the whole DSL thing, then yes, templated HTML
with tags in it is the way to go for you.. ala Ruby on Rails. However,
I'd wager the productivity of a seaside developer is significantly
higher than that of a rails developer once you get past the initial CRUD
screens.

To put the problem another way - imagine having a GUI framework that
didn't have callbacks, that you had to define the screen with an id and
the model with an id and you got a bunch of field changes in bulk when
the user hits 'save'. It'd be rather awkward programming. The lack of
events is significant enough that you'd just plain give up.

So why didn't people give up? .. well this browser thing was already on
every microsoft windows computer and it gave you a workable
client-server model. More recently, with some smart Javascript
libraries, we've managed to get back callbacks, events, per-field
updating and validating.. all the things we expect from a GUI framework.

But now we have all these fiddle 'things' we have to do to each and
event field or form or label just to make it do what we want. Naturally,
the answer here is to employ a more powerful templating system - so
powerful it may as well be a programming language.

<label for="i3838" class="mandatory error" title="Mandatory field"><img
src="error.gif" alt="Mandatory field"/><a
name="name"/>Name:</label><input type="text" name="name" id="i3838"
class="mandatory error input template" value="Full name"
onfocus="this.value == ''; this.removeClass('template');" onblur="if
(this.value == '') { this.addClass('template'). this.value = 'Full
name'; }" onchange="ajaxUpdate(this);"/>

Or.. I could write:

self addLabel: 'Name' isMandatory: true inputTemplate: 'Full name'
object: myObject aspect: #name.

Which would you rather call? The intricate mess of XHTML, CSS and
Javascript makes templating pretty much impossible now. Higher level
DSLs are needed to more accurately describe the user interface.

So, in the long response, it seems my answer is, Seaside makes some
things that are impossible - possible and makes some things that are
repetitive, error prone or just plain hard - easy.

Cheers,
Michael

Dennis Smith wrote:

(Repost, as I "michael" don't think it got to vwnc)

It sounds like you're coming at this from the angle of someone who has
never suffered the horror of vignette, jsp's, asp's, php, cold fusion,
plain html editing with/without a html editor.

In many respects the answer to your question is this: Seaside catches us
back up with the gui's core capabilities - connecting the screen to the
domain. The next step beyond that would be to make a ui builder for it -
some people are doing that.

It turns out that what we desire the most in web applications is
granular composition. You don't really get that by breaking your program
up in to hundreds of small html files and pasting them together with
application code that links back to another page which interprets the
form data and calls your domain code to then do the whole thing over
again. So Seaside encapsulates that pattern for you. Call/Return is more
like going from an edit window, to picking a search button on a field to
find a person to drop in to the 'seller' box.

Granular composition of pages and behaviour is always best done as close
to the domain as possible - so naturally smalltalk fits in like a charm.
If you don't subscribe to the whole DSL thing, then yes, templated HTML
with tags in it is the way to go for you.. ala Ruby on Rails. However,
I'd wager the productivity of a seaside developer is significantly
higher than that of a rails developer once you get past the initial CRUD
screens.

To put the problem another way - imagine having a GUI framework that
didn't have callbacks, that you had to define the screen with an id and
the model with an id and you got a bunch of field changes in bulk when
the user hits 'save'. It'd be rather awkward programming. The lack of
events is significant enough that you'd just plain give up.

So why didn't people give up? .. well this browser thing was already on
every microsoft windows computer and it gave you a workable
client-server model. More recently, with some smart Javascript
libraries, we've managed to get back callbacks, events, per-field
updating and validating.. all the things we expect from a GUI framework.

But now we have all these fiddle 'things' we have to do to each and
event field or form or label just to make it do what we want. Naturally,
the answer here is to employ a more powerful templating system - so
powerful it may as well be a programming language.

<label for="i3838" class="mandatory error" title="Mandatory field"><img
src="error.gif" alt="Mandatory field"/><a
name="name"/>Name:</label><input type="text" name="name" id="i3838"
class="mandatory error input template" value="Full name"
onfocus="this.value == ''; this.removeClass('template');" onblur="if
(this.value == '') { this.addClass('template'). this.value = 'Full
name'; }" onchange="ajaxUpdate(this);"/>

Or.. I could write:

self addLabel: 'Name' isMandatory: true inputTemplate: 'Full name'
object: myObject aspect: #name.

Which would you rather call? The intricate mess of XHTML, CSS and
Javascript makes templating pretty much impossible now. Higher level
DSLs are needed to more accurately describe the user interface.

So, in the long response, it seems my answer is, Seaside makes some
things that are impossible - possible and makes some things that are
repetitive, error prone or just plain hard - easy.

Cheers,
Michael

Dennis Smith wrote: