YUI

Todd Blanchard wrote:
> Eh - seems like they're trying a little too hard to look like
> Windows.   I'd have to see how easy it is to style things for
> different looks.  I've seen the themes posted - they just address
> color scheme.
>
>
Yes, as I said, not perfect for everyone or every app.  As for themes,
you have a fair amount of control of how things look even without
creating your own theme (all of the components support CSS class
configuration for most of their visual parts).  I haven't found a need
for it b/c "like Windows" is better looking that "David Shaffer's crappy
artisticless-ness rendering" :-) :-) :-)

David

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Sebastian Sastre wrote:


> So maybe it's time to evaluate the option. I think before convincing myself
> of that having sense I would:
>
> 1. one should quantify that impedance
>  
a) All UI-related state of the components is on the client.  Smalltalk
side only informed of desired events.  This really isn't much different
than the usual HTML input components.  It is also very similar to
"native widget" GUI interfaces found in some Smalltalks.  Much of the
debate of native versus emulated widgets applies here.

b) Events provided by the client can be handled by JS in the client or
by Smalltalk (via Ajax) in Smalltalk.  Just as with Scriptaculous.

c) There are very few full page redraws so renderContentOn: needs to be
well factored so that parts of a component can be re-drawn as needed.

> 2. see if one finds a mapping design that is useful for the long run
>  
...I can't address this.  Maybe once this full app is deployed.
> 3. see if the the life of ExtJS will be long enough to make this worth
>  
One never knows about these things.  The have a solid product, large
community and great support.
> 4. evaluate ExtJS community support
>  
above
> 5. see if the design will pollute or not the seaside-smalltalk way to do
> things (easiness to virtualize conceptual models)
>  
If you aren't careful your Smalltalk code looks like "Javascript in
Smalltalk".  I tried the approach Lukas provided with Scriptaculous
(Smalltalk objects represent Javascript statements, can be decorated
etc) but it was too verbose.  I've looked at ST2JS and finally think I
understand it but I think it might be taking things a bit too far.  
Right now I'm looking for something in the middle.  I want to write
Smalltalk-looking code which manipulates Javascript objects.  I want the
API of these Javascript objects to be explicit in Smalltalk whenever
possible with the option of having "generic objects" when I'm not sure
of the return type of something.  I'd like to be able to perform
Smalltalk computations that aren't translated to Javascript as well as
pass Smalltalk blocks to be used as callbacks.  This is a challenge.


> Why we can't have our own (community) hierarchy of gorgeous widgets on top
> of smalltalk-seaside-prototype-scriptaculous?
>
>  
This just hasn't happened.  The Seaside "components" that you can find
simply don't cover as broad a spectrum as something like ExtJS.  
Producing this kind of tool set in Smalltalk is outside my area of
expertise (and interest).  Having said that I'd much rather work on an
app that didn't require something like ExtJS because there's always that
feeling that you can't deal with problems if they occur.  Fortunately
armed with Firebug and a rough knowledge of Javascript I haven't hit any
snags.

David

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Yes I also see this. The question here is what in the html/javascript domain
would be more convenient for us?
Before trying to answer that I think in two things: 1) how many changes the
OS native widgets has experimented, so it's programatic interfaces and 2)
how many widgets you found in the web domain (I see a lot more). Seeing
those two considerations now I'm wondering how to ponder how much clever
could be an early compromise with a "native" widget implementation for the
web domain. Experience indicates that Smalltalk solutions use to perdure.

> b) Events provided by the client can be handled by JS in the
> client or by Smalltalk (via Ajax) in Smalltalk.  Just as with
> Scriptaculous.
>

I don't saw requests while using it so I think they are also using comet or
something like that.

> c) There are very few full page redraws so renderContentOn:
> needs to be well factored so that parts of a component can be
> re-drawn as needed.
>

Naturally that is needed for any option. For instance I already done that
for some presenters (seaside components) in the MVP hierarchy I made for my
widgets.

Totally agree. That's why I factorized things to the point of being able to
use a Smaltalkish well proven framework like MVP. When I need an updater in
a presenter I call it and only customize it's callback so verbosity is not
my problem anymore. Hierarchies of similar "widgets" form families of
presenters with factorable scripts and so on.
Indeed it is. The problem is that you don’t have the javascript part enough
prepared to perform a smalltalk experience. Think in our debugger. Believe
me I've tried to give a little step in that direction. Using javascript
objects ala Smalltalk is too much for the JS VM that todays barely performs
reasonable garbages collections. A JS Dictionary performs miserably todays.
That’s why it's used so "hackishly". Improvments in JS VM will help us all
but that it's not in our hands.
Of course not that's why I instigated us with my question :)

I'm still conviced (since 2003 or somethig like that) that the MVP pattern
also applies to the web domain taking advantage of seaside using prototype
and scriptaculous as if they where the low level API that the OS gives you
in the metaphore: web browsers are our new OS.

We all love out of the box solutions but in smalltalk we have to make it
happen !
I like to see this happening in Smalltalk - Seaside,

        cheers,

Sebastian

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

He he, ok but not all that shines is gold. I saw application interfaces with
humble widgets but with superior heuristic scoring than an equivalent
application with glamorous native widgets.

So why you want to repeat a formula with systematic disrespect to heuristic
principles if you can give a better experience not needing to "desktopize"
the web widgets?

Cheers,

Sebastian

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Sebastian Sastre wrote: Maybe that was a rhetorical question?  Anyway, the heuristic depends on
the application and its audience.  My feeling is that the ExtJS
component set scores well for the application I'm working on now.  My
gold-owner/goal-donor is willing to bank on it so right now that's the
way we're going.  I agree 100% with many of the sentiments expressed in
this thread w/ regards to needing a rich Seaside/Smalltalk-based
component set.  I also think that there are few among us who know enough
about "the browser as a client platform" to produce it.  In any case my
deadline looms and my requirements are currently met by parts of ExtJS.

David

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On Wed, October 31, 2007 12:11 pm, C. David Shaffer wrote:

> ... I agree 100% with many of the sentiments expressed in
> this thread w/ regards to needing a rich Seaside/Smalltalk-based
> component set.  I also think that there are few among us who know enough
> about "the browser as a client platform" to produce it.  In any case my
> deadline looms and my requirements are currently met by parts of ExtJS.

I was initially toying around w/ YUI in a vain attempt to get their menu
system plugged into Seaside building upon what Boris had published a while
back.. Unfortunately, I found that converting their framework into something
that made sense (to me at least) in a ST sort of way didn't really jive for
me and I never got too far.. It was rather ugly and all..

Personally, I'd love to see something that would allow a nice Seaside/ST
interface for a menu system similar to what either YUI or ExtJS provides..
However, as mentioned earlier in this thread I think that one of the hard
parts is trying to make it not only play in our environment but also that
it makes sense..  Oh well.. Time to take the kids out for some trick or
treating.. (8->

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

In fact the heuristic scoring will depend just on the product not to
disrespect it's principles (wich anybody can easily google to know about).
For instance desktops like Windows (seems the ExtJS goal)  fails miserably
and systematically (just hear users complains). We can do better. But if we
copy what we know that is wrong we had compromised our chance to do better.
Anyway that it's about user experience.

About your choice I guarantee you my best wishes in your challenge. For sure
I'll have interest in hear about your results and/or experience making that,
not to mention code of a new resource for this community from you.

        All the best,

Sebastian

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

>From reading the blog entries on prototype, it looks
like the problem is that it exposes badly written
code. Composable javascript should work within those
prototype walls.

Stephan
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> From reading the blog entries on prototype, it looks
> like the problem is that it exposes badly written
> code. Composable javascript should work within those
> prototype walls.

It is indisputable that Prototypes extends the global namespace and
existing objects in ways that might conflict with other libraries. I
personally find it very well written, though.

Prototype takes many ideas from Smalltalk (actually Ruby, but 'taking
an idea' is transitive). If that was not the case, having the
possibility to write something like the following expression in
Smalltalk

    ((SUSelector new matching: 'div.hint')
        select: [ :each | each element visible not ])
        do: [ :each | each effect appear ]

and automatically transform it to JavaScript

    $$('div.hint').findAll(function(){return
!$(arguments[0]).visible()}).each(function(){new
Effect.Appear(arguments[0])})

would be much harder.

Ideally we had a library that was designed for Seaside and Smalltalk.
In practice resources are missing to do that. The amount of mails
discussion about what could be done represents in no way what is
actually done. Prototype is a reasonable match in that sense.

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Hi,

        I remember one time I was interested in the results that the Dojo
Toolkit achieved. Now I see it's demos barely running well even with the
support from IBM they seems to get.

        I agree with Lukas and I'm experimenting that Prototype is a good
choice. Also remember that Prototipe is a product from a affine community, a
community that is technologically very near this one.

        cheers,

Sebastian Sastre


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

"C. David Shaffer" <[hidden email]> wrote in message
news:[hidden email]...
> a) All UI-related state of the components is on the client.  Smalltalk
> side only informed of desired events.
> b) Events provided by the client can be handled by JS in the client or by
> Smalltalk (via Ajax) in Smalltalk.  Just as with Scriptaculous.
>
> c) There are very few full page redraws so renderContentOn: needs to be
> well factored so that parts of a component can be re-drawn as needed.

I would love to see the result of this direction, and how well it can be
made to fit what's already on the sea side.




_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside