Smalltalk › Frameworks & Tools › Seaside › Seaside General

Pondering if Dojo javascript toolkit is more convenient than Scriptaculous for Seaside solutions

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

11 messages Options

Sebastian Sastre-2

Pondering if Dojo javascript toolkit is more convenient than Scriptaculous for Seaside solutions

Hi there,

I like to share some ideas about the value equation (scoring) of Seaside systems (solutions) and to purpouse to evaluate somethig that I suspect that could add value this equation so, if this suspiction is finally right, it will add value for all the comunity, so we all won.

Imagine you have a scoring equation wich defines the value of your seasside solution. This equation have the general form of: X1+X2+..+Xn

Each term is a function of value (scoring) of different domains: for instance.. X1 is loadbalance, X2 is memory scalability, X3 is processor scalability, X4 is complexity scalability, etc. As the terms can be complex scoring functions, this equation is also a sort of composite if we'll express it in "patternese".

Given that, I want to make focus on two terms that are important for developers: 1. Content and 2. Form.

For (non static) web applications (or online systems as I like to say) Seaside is a framework that irrefutably takes care of "the contents" and solves basically and consistently "the form" using html and CSS. In the form term I want to ponder a (sub)equation of two terms:

1. Usability. The digital ergonomy. The empirical ease of use of the systems. The facilities that your applications had to offer to end (daily?) users.

2. Cosmetic. The indumentary of the systems. Pure eye candy makeup which users like to, as it's clothes, be able to renew often and flexibly and numerously.

For the contents I have no further comments because I consider Seaside to be vanguardist and by far the best in it's field. So for me, content has reached irrefutability. This means that for the "sale" (final score value) this term sells OK. Now.. for the form (usability+cosmetic) we have reached an acceptable scoring but I think I found a way in wich we can improve those terms in a way in direction of form (usability+cosmetic) irrefutable scores.

Said that, the concrete purpouse is to evaluate Dojo javascript toolkit as being used for Seaside applications. (see: http://dojotoolkit.org/)

I read that Dojo is ready to be use from Ruby so I think that nothing should stop us to use it also from Seaside. Seems to be that Dojo community has some support from IBM so this should weight something in the balance. A first look into the demos could show you nice form value. If you take a look on the widgets in the API documentation, try to forget cosmetic for a moment and see the usability that those widgets have to offer (and I mean the contents and not how they made the documentation interface). Take a look into the panes with draggeable splitters for instance. That can't be done with css. CSS can't even give us (yet) an appropiated general solution for elemental #north, #south, #center automatic layouts. To make that you end up using CSS hacks that leads you to have an early compromise with the page shape. This deteriorates the "desktopability" of web applications.

I don't know you but I found those widgets very good in what they do and I think that to have them in sum to seaside applications will rise the score of seaside solutions significantly.

My experience shows that wrapping this toolkit should lead us to a hierarchy as rich as any Smalltalk View hierarchy of a Smalltalk that is using native widgets. So this means coupling because the classes end up wrapping system events and calls to build the views. Here there will be Dojo events and Dojo calls to build up the windows (yes it can do windows inside a page) in the browser. But the add of coupling will be with a cross-platform javascript widgets framework so we won vanguardist widgets smalltalkish way usable that work for lots of browsers in lots of OS's. So with this choice we end up using javascript calls as the dlls (or homologous) libraries calls of a native system (which is the browser in this case).

Finally, if a Seaside is about the "descktopability" of web applications, then Seaside+Dojo could be a good deal. Once the wrapping it's done and maintained, It will modify the whole equation allowing the whole score to raise more dramatically for the same development effort. That will maintain Seaside and Smalltalk itself to the vanguard allowing the creation of Smalltalk solutions of high real value. An ammount of value that other web application frameworks could only dream about.

Now the realistic questions:

Why do you or do you not found Dojo a convenient choice?

Beside Scriptaculous, do you know another choice than Dojo? it will lead us to where? how far?

Do you admit that wrapping Dojo will lead us to a View hierarchy?

Admiting that this frameworks are a View...

Do you found Model-View-Controller can be used in Seaside applications?

Do you found Model-View-Presenter more suitable?

Do you found another event-model-view glue more convenient than those? which one? why?

cheers,

Sebastian Sastre

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

Boris Popov, DeepCove Labs (SNN)

RE: Pondering if Dojo javascript toolkit is more convenientthan Scriptaculous for Seaside solutions

I don't see any harm in using whatever JS toolkit that would make your
life easier. Here, for instance, we use both Scriptaculous/Prototype and
YUI extensively, even mixed together,

(html anchor)
class: 'settings';
onClick: (html
yuipanel: editor
config: [:v | v close: true]);
with: 'Settings'

where,

yuipanel: component config: block
(self updater)
evalScripts: true;
id: 'yuipaneltarget';
onFailure: ((SUStream new)
nextPutAll: 'displayGenericError();';
yourself);
callback: [:render |
| dialog |
dialog := (Seaside.YUIPanel new)
immediate: true;
delegate: component;
yourself.
block value: dialog.
dialog renderContentOn: render];
yourself

So it's really up to you to decide what tool is right for the job.

-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.

> -----Original Message-----
> From: [hidden email] [mailto:seaside-
> [hidden email]] On Behalf Of Sebastian Sastre
> Sent: Thursday, April 26, 2007 10:28 AM
> To: 'Seaside - general discussion'
> Subject: [Seaside] Pondering if Dojo javascript toolkit is more
> convenientthan Scriptaculous for Seaside solutions
>
> Hi there,
>
> I like to share some ideas about the value equation (scoring) of
> Seaside systems (solutions) and to purpouse to evaluate somethig that

I
> suspect that could add value this equation so, if this suspiction is
> finally right, it will add value for all the comunity, so we all won.
>
> Imagine you have a scoring equation wich defines the value of your
> seasside solution. This equation have the general form of:
X1+X2+..+Xn
>
> Each term is a function of value (scoring) of different domains:
for
> instance.. X1 is loadbalance, X2 is memory scalability, X3 is
processor
> scalability, X4 is complexity scalability, etc. As the terms can be
> complex scoring functions, this equation is also a sort of composite
if
> we'll express it in "patternese".
>
> Given that, I want to make focus on two terms that are important
for
> developers: 1. Content and 2. Form.
>
> For (non static) web applications (or online systems as I like to
say)
> Seaside is a framework that irrefutably takes care of "the contents"
and
> solves basically and consistently "the form" using html and CSS. In
the
> form term I want to ponder a (sub)equation of two terms:
>
> 1. Usability. The digital ergonomy. The empirical ease of use of
the
> systems. The facilities that your applications had to offer to end
> (daily?) users.
> 2. Cosmetic. The indumentary of the systems. Pure eye candy makeup
> which users like to, as it's clothes, be able to renew often and
flexibly
> and numerously.
>
> For the contents I have no further comments because I consider
Seaside
> to be vanguardist and by far the best in it's field. So for me,
content
> has reached irrefutability. This means that for the "sale" (final
score
> value) this term sells OK. Now.. for the form (usability+cosmetic) we
have
> reached an acceptable scoring but I think I found a way in wich we can
> improve those terms in a way in direction of form (usability+cosmetic)
> irrefutable scores.
>
> Said that, the concrete purpouse is to evaluate Dojo javascript
> toolkit as being used for Seaside applications. (see:
> http://dojotoolkit.org/)
>
> I read that Dojo is ready to be use from Ruby so I think that
nothing
> should stop us to use it also from Seaside. Seems to be that Dojo
> community has some support from IBM so this should weight something in
the
> balance. A first look into the demos could show you nice form value.
If
> you take a look on the widgets in the API documentation, try to forget
> cosmetic for a moment and see the usability that those widgets have to
> offer (and I mean the contents and not how they made the documentation
> interface). Take a look into the panes with draggeable splitters for
> instance. That can't be done with css. CSS can't even give us (yet) an
> appropiated general solution for elemental #north, #south, #center
> automatic layouts. To make that you end up using CSS hacks that leads
you
> to have an early compromise with the page shape. This deteriorates the
> "desktopability" of web applications.
>
> I don't know you but I found those widgets very good in what they
do
> and I think that to have them in sum to seaside applications will rise
the
> score of seaside solutions significantly.
>
> My experience shows that wrapping this toolkit should lead us to a
> hierarchy as rich as any Smalltalk View hierarchy of a Smalltalk that
is
> using native widgets. So this means coupling because the classes end
up
> wrapping system events and calls to build the views. Here there will
be
> Dojo events and Dojo calls to build up the windows (yes it can do
windows
> inside a page) in the browser. But the add of coupling will be with a
> cross-platform javascript widgets framework so we won vanguardist
widgets
> smalltalkish way usable that work for lots of browsers in lots of
OS's. So
> with this choice we end up using javascript calls as the dlls (or
> homologous) libraries calls of a native system (which is the browser
in
> this case).
>
> Finally, if a Seaside is about the "descktopability" of web
> applications, then Seaside+Dojo could be a good deal. Once the
wrapping
> it's done and maintained, It will modify the whole equation allowing
the
> whole score to raise more dramatically for the same development
effort.
> That will maintain Seaside and Smalltalk itself to the vanguard
allowing
> the creation of Smalltalk solutions of high real value. An ammount of
> value that other web application frameworks could only dream about.
>
> Now the realistic questions:
>
> Why do you or do you not found Dojo a convenient choice?
> Beside Scriptaculous, do you know another choice than Dojo? it
> will lead us to where? how far?
> Do you admit that wrapping Dojo will lead us to a View
hierarchy?

> Admiting that this frameworks are a View...
> Do you found Model-View-Controller can be used in Seaside
> applications?
> Do you found Model-View-Presenter more suitable?
> Do you found another event-model-view glue more convenient
> than those? which one? why?
>
> cheers,
>
> Sebastian Sastre
>
>

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

Damien Cassou-3

Re: Pondering if Dojo javascript toolkit is more convenientthan Scriptaculous for Seaside solutions

I would really like to have moveable widgets in seaside without any
modification to the original component. This would be a great
advertisement over seaside components.

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

Sebastian Sastre-2

RE: Pondering if Dojo javascript toolkit is moreconvenientthan Scriptaculous for Seaside solutions

In reply to this post by Boris Popov, DeepCove Labs (SNN)

> I don't see any harm in using whatever JS toolkit that would
> make your life easier. Here, for instance, we use both
> Scriptaculous/Prototype and YUI extensively, even mixed together,
>
Right. And I wrote that because I've found Dojo could lead us to a far more
complete UI solution than Scriptaculous and even Yahoo UI (I don't know
about Prototype). Is not that they aren't good. I use some Scriptaculous
myself as you say. But one (and customers and consumers) allways want more
right? So I'm talking about the near future of Seaside based online systems.

Perhaps I'm worried more because I have no idea of what javascript develop
could mean, and that I don't want to know what that mean, but I do like the
results I've see. I'm aware that those results are valuable javascript that
could bring us cosmetic, usability and ajaxian (events) but no more than
that. For the rest is Seaside and Smalltalk itself.

So I'm questioning here if the community could use some coordinated effort
on mapping Dojo to go togheter further adding Dojo features to Seaside
sarting today in contrast with fragmentated efforts that could (or could
not) be reached and perhaps adopted tomorrow.

So.. Did you take a look into Dojo widgets?

Regards,

Sebastian

> (html anchor)
> class: 'settings';
> onClick: (html
> yuipanel: editor
> config: [:v | v close: true]);
> with: 'Settings'
>
> where,
>
> yuipanel: component config: block
> (self updater)
> evalScripts: true;
> id: 'yuipaneltarget';
> onFailure: ((SUStream new)
> nextPutAll: 'displayGenericError();';
> yourself);
> callback: [:render |
> | dialog |
> dialog := (Seaside.YUIPanel new)
> immediate: true;
> delegate: component;
> yourself.
> block value: dialog.
> dialog renderContentOn: render];
> yourself
>
> So it's really up to you to decide what tool is right for the job.
>
> -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.
>
> > -----Original Message-----
> > From: [hidden email] [mailto:seaside-
> > [hidden email]] On Behalf Of Sebastian Sastre
> > Sent: Thursday, April 26, 2007 10:28 AM
> > To: 'Seaside - general discussion'
> > Subject: [Seaside] Pondering if Dojo javascript toolkit is more
> > convenientthan Scriptaculous for Seaside solutions
> >
> > Hi there,
> >
> > I like to share some ideas about the value equation
> (scoring) of
> > Seaside systems (solutions) and to purpouse to evaluate
> somethig that
> I
> > suspect that could add value this equation so, if this
> suspiction is
> > finally right, it will add value for all the comunity, so
> we all won.
> >
> > Imagine you have a scoring equation wich defines the
> value of your
> > seasside solution. This equation have the general form of:
> X1+X2+..+Xn
> >
> > Each term is a function of value (scoring) of different domains:
> for
> > instance.. X1 is loadbalance, X2 is memory scalability, X3 is
> processor
> > scalability, X4 is complexity scalability, etc. As the terms can be
> > complex scoring functions, this equation is also a sort of composite
> if
> > we'll express it in "patternese".
> >
> > Given that, I want to make focus on two terms that are important
> for
> > developers: 1. Content and 2. Form.
> >
> > For (non static) web applications (or online systems as
> I like to
> say)
> > Seaside is a framework that irrefutably takes care of "the contents"
> and
> > solves basically and consistently "the form" using html and CSS. In
> the
> > form term I want to ponder a (sub)equation of two terms:
> >
> > 1. Usability. The digital ergonomy. The empirical ease of use of
> the
> > systems. The facilities that your applications had to offer to end
> > (daily?) users.
> > 2. Cosmetic. The indumentary of the systems. Pure eye
> candy makeup
> > which users like to, as it's clothes, be able to renew often and
> flexibly
> > and numerously.
> >
> > For the contents I have no further comments because I consider
> Seaside
> > to be vanguardist and by far the best in it's field. So for me,
> content
> > has reached irrefutability. This means that for the "sale" (final
> score
> > value) this term sells OK. Now.. for the form
> (usability+cosmetic) we
> have
> > reached an acceptable scoring but I think I found a way in
> wich we can
> > improve those terms in a way in direction of form
> (usability+cosmetic)
> > irrefutable scores.
> >
> > Said that, the concrete purpouse is to evaluate Dojo javascript
> > toolkit as being used for Seaside applications. (see:
> > http://dojotoolkit.org/)
> >
> > I read that Dojo is ready to be use from Ruby so I think that
> nothing
> > should stop us to use it also from Seaside. Seems to be that Dojo
> > community has some support from IBM so this should weight
> something in
> the
> > balance. A first look into the demos could show you nice form value.
> If
> > you take a look on the widgets in the API documentation,
> try to forget
> > cosmetic for a moment and see the usability that those
> widgets have to
> > offer (and I mean the contents and not how they made the
> documentation
> > interface). Take a look into the panes with draggeable
> splitters for
> > instance. That can't be done with css. CSS can't even give
> us (yet) an
> > appropiated general solution for elemental #north, #south, #center
> > automatic layouts. To make that you end up using CSS hacks
> that leads
> you
> > to have an early compromise with the page shape. This
> deteriorates the
> > "desktopability" of web applications.
> >
> > I don't know you but I found those widgets very good in
> what they
> do
> > and I think that to have them in sum to seaside
> applications will rise
> the
> > score of seaside solutions significantly.
> >
> > My experience shows that wrapping this toolkit should
> lead us to a
> > hierarchy as rich as any Smalltalk View hierarchy of a
> Smalltalk that
> is
> > using native widgets. So this means coupling because the classes end
> up
> > wrapping system events and calls to build the views. Here there will
> be
> > Dojo events and Dojo calls to build up the windows (yes it can do
> windows
> > inside a page) in the browser. But the add of coupling will
> be with a
> > cross-platform javascript widgets framework so we won vanguardist
> widgets
> > smalltalkish way usable that work for lots of browsers in lots of
> OS's. So
> > with this choice we end up using javascript calls as the dlls (or
> > homologous) libraries calls of a native system (which is the browser
> in
> > this case).
> >
> > Finally, if a Seaside is about the "descktopability" of web
> > applications, then Seaside+Dojo could be a good deal. Once the
> wrapping
> > it's done and maintained, It will modify the whole equation allowing
> the
> > whole score to raise more dramatically for the same development
> effort.
> > That will maintain Seaside and Smalltalk itself to the vanguard
> allowing
> > the creation of Smalltalk solutions of high real value. An
> ammount of
> > value that other web application frameworks could only dream about.
> >
> > Now the realistic questions:
> >
> > Why do you or do you not found Dojo a convenient choice?
> > Beside Scriptaculous, do you know another choice
> than Dojo? it
> > will lead us to where? how far?
> > Do you admit that wrapping Dojo will lead us to a View
> hierarchy?
> > Admiting that this frameworks are a View...
> > Do you found Model-View-Controller can be used
> in Seaside
> > applications?
> > Do you found Model-View-Presenter more suitable?
> > Do you found another event-model-view glue more
> convenient
> > than those? which one? why?
> >
> > cheers,
> >
> > Sebastian Sastre
> >
> >
>
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

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

Sebastian Sastre-2

RE: Pondering if Dojo javascript toolkit is moreconvenientthan Scriptaculous for Seaside solutions

In reply to this post by Damien Cassou-3

> -----Mensaje original-----
> De: [hidden email]
> [mailto:[hidden email]] En nombre
> de Damien Cassou
> Enviado el: Jueves, 26 de Abril de 2007 15:36
> Para: Seaside - general discussion
> Asunto: Re: [Seaside] Pondering if Dojo javascript toolkit is
> moreconvenientthan Scriptaculous for Seaside solutions
>
> I would really like to have moveable widgets in seaside
> without any modification to the original component. This
> would be a great advertisement over seaside components.
>

And Damien, do you agree that what you say could be archievable just using
a, let's say DojoRenderer, that undestands (as polymophinc as it can) how to
render Dojo widgets in your application components?
I'm a Smalltalk Seaside enthusiast in first place but I think that for non
seasider nor smalltalker users, the perception of the value of the
technologic choice could be compromised, and by the eye they will perceive
our solutions more valuable when demostrated in such a fashion as Dojo could
deliver. The solution will enter (door) by the eye and will end up
demostrating it's functionality strenghts (once passed by the door) by the
brain,

Cheers,

Sebastian Sastre

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

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

Philippe Marschall

Re: Pondering if Dojo javascript toolkit is more convenient than Scriptaculous for Seaside solutions

In reply to this post by Sebastian Sastre-2

2007/4/26, Sebastian Sastre <[hidden email]>:

>
>
> Hi there,
>
> I like to share some ideas about the value equation (scoring) of Seaside
> systems (solutions) and to purpouse to evaluate somethig that I suspect that
> could add value this equation so, if this suspiction is finally right, it
> will add value for all the comunity, so we all won.
>
> Imagine you have a scoring equation wich defines the value of your
> seasside solution. This equation have the general form of: X1+X2+..+Xn
>
> Each term is a function of value (scoring) of different domains: for
> instance.. X1 is loadbalance, X2 is memory scalability, X3 is processor
> scalability, X4 is complexity scalability, etc. As the terms can be complex
> scoring functions, this equation is also a sort of composite if we'll
> express it in "patternese".
>
> Given that, I want to make focus on two terms that are important for
> developers: 1. Content and 2. Form.
>
> For (non static) web applications (or online systems as I like to say)
> Seaside is a framework that irrefutably takes care of "the contents" and
> solves basically and consistently "the form" using html and CSS. In the form
> term I want to ponder a (sub)equation of two terms:
>
>
> 1. Usability. The digital ergonomy. The empirical ease of use of the
> systems. The facilities that your applications had to offer to end (daily?)
> users. 2. Cosmetic. The indumentary of the systems. Pure eye candy makeup
> which users like to, as it's clothes, be able to renew often and flexibly
> and numerously.
>
> For the contents I have no further comments because I consider Seaside
> to be vanguardist and by far the best in it's field. So for me, content has
> reached irrefutability. This means that for the "sale" (final score value)
> this term sells OK. Now.. for the form (usability+cosmetic) we have reached
> an acceptable scoring but I think I found a way in wich we can improve those
> terms in a way in direction of form (usability+cosmetic) irrefutable scores.
>
> Said that, the concrete purpouse is to evaluate Dojo javascript toolkit
> as being used for Seaside applications. (see: http://dojotoolkit.org/)
>
> I read that Dojo is ready to be use from Ruby so I think that nothing
> should stop us to use it also from Seaside. Seems to be that Dojo community
> has some support from IBM so this should weight something in the balance. A
> first look into the demos could show you nice form value. If you take a look
> on the widgets in the API documentation, try to forget cosmetic for a moment
> and see the usability that those widgets have to offer (and I mean the
> contents and not how they made the documentation interface). Take a look
> into the panes with draggeable splitters for instance. That can't be done
> with css. CSS can't even give us (yet) an appropiated general solution for
> elemental #north, #south, #center automatic layouts. To make that you end up
> using CSS hacks that leads you to have an early compromise with the page
> shape. This deteriorates the "desktopability" of web applications.
>
> I don't know you but I found those widgets very good in what they do and
> I think that to have them in sum to seaside applications will rise the score
> of seaside solutions significantly.
>
> My experience shows that wrapping this toolkit should lead us to a
> hierarchy as rich as any Smalltalk View hierarchy of a Smalltalk that is
> using native widgets. So this means coupling because the classes end up
> wrapping system events and calls to build the views. Here there will be Dojo
> events and Dojo calls to build up the windows (yes it can do windows inside
> a page) in the browser. But the add of coupling will be with a
> cross-platform javascript widgets framework so we won vanguardist widgets
> smalltalkish way usable that work for lots of browsers in lots of OS's. So
> with this choice we end up using javascript calls as the dlls (or
> homologous) libraries calls of a native system (which is the browser in this
> case).
>
> Finally, if a Seaside is about the "descktopability" of web
> applications, then Seaside+Dojo could be a good deal. Once the wrapping it's
> done and maintained, It will modify the whole equation allowing the whole
> score to raise more dramatically for the same development effort. That will
> maintain Seaside and Smalltalk itself to the vanguard allowing the creation
> of Smalltalk solutions of high real value. An ammount of value that other
> web application frameworks could only dream about.
>
> Now the realistic questions:
>
> Why do you or do you not found Dojo a convenient choice?
> Beside Scriptaculous, do you know another choice than Dojo?

MooTools
http://mootools.net/

Cheers
Philippe

> it will
> lead us to where? how far?
> Do you admit that wrapping Dojo will lead us to a View hierarchy?
> Admiting that this frameworks are a View...
> Do you found Model-View-Controller can be used in Seaside
> applications?
> Do you found Model-View-Presenter more suitable?
> Do you found another event-model-view glue more convenient than
> those? which one? why?
>
> cheers,
>
>
>
> Sebastian Sastre
>
>
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
>

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

Rick Flower

Re: Pondering if Dojo javascript toolkit is more convenientthan Scriptaculous for Seaside solutions

In reply to this post by Boris Popov, DeepCove Labs (SNN)

Boris Popov wrote:

> I don't see any harm in using whatever JS toolkit that would make your
> life easier. Here, for instance, we use both Scriptaculous/Prototype and
> YUI extensively, even mixed together,
>
> (html anchor)
> class: 'settings';
> onClick: (html
> yuipanel: editor
> config: [:v | v close: true]);
> with: 'Settings'
>
> where,
>
> yuipanel: component config: block
> (self updater)
> evalScripts: true;
> id: 'yuipaneltarget';
> onFailure: ((SUStream new)
> nextPutAll: 'displayGenericError();';
> yourself);
> callback: [:render |
> | dialog |
> dialog := (Seaside.YUIPanel new)
> immediate: true;
> delegate: component;
> yourself.
> block value: dialog.
> dialog renderContentOn: render];
> yourself
>
> So it's really up to you to decide what tool is right for the job.

When doing this sort of stuff (integrating a new js library w/ Seaside),
is there any rhyme or reason as to whether certain functionality should
be subclassed from WADecoration vs. WAComponent, etc and perhaps more
specifically how detailed it's "api" should be and if I should try to
use standardized keywords where possible? I've taken Boris'
latest (but a bit dated at this point) version of SeasideYUI and updated
the embedded js code for YUI, and added a first whack at yuimenu support
which I've got subclassed from WADecoration.. However, I'm finding that
the use of it is a bit verbose and it would be nicer to bury some of the
details in some form of an object and perhaps have it emit some of the
nested divs,etc.

I guess it might be nice to be able to do something like this -- in the
case of a yuimenu:

renderContentOn: html
html yuimenu id: #foo with: [
html yuimenuitem id: #bar with: [
html anchor callback: [ self blah ]; with: 'MyLink'
]
]

My initial code currently uses lots of nested divs, unordered lists,
list items, etc. Fairly verbose even for small menus.. Using something
like above would really hide a bunch of the crap behind the scenes..
But, perhaps people want to see that stuff? Anyway, just thought I'd ask..

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

Boris Popov, DeepCove Labs (SNN)

RE: Pondering if Dojo javascript toolkit ismore convenientthan Scriptaculous for Seaside solutions

In most cases where you'd like to emit this kind of thing, what you're
really looking for is a simple subclass of WABrush, for instance I have
a thing called ChartTag,

ChartTag>>initialize
super initialize.
size := 100 @ 100.
type := Charts flash: 'Column2D'.
callback := [:xml | ]

ChartTag>>with: aBlock
| div |
canvas forgetCurrentBrush.
div := canvas div.
canvas script: ('var chart<1s> = new FusionCharts("<2s>",
"mychart<1s>", "<4p>", "<5p>", "0", "0"); chart<1s>.setDataURL("<3s>");
chart<1s>.render("<1s>");'
expandMacrosWithArguments:
((OrderedCollection new)
add: div ensureId;
add: (canvas absoluteUrlForResource: type);
add: (URI encode: (canvas urlForCharts: callback) allowed: '');
add: size x;
add: size y;
yourself))

RenderCanvas>>chart
^self brush: ChartTag new

RenderCanvas>>chart: aBlock
^self chart with: aBlock

all of which gets used just as any other brush,

(html div)
style: 'padding-top: 0.5em;';
with: [(html chart)
type: (Charts flash: 'Column2D');
size: 610 @ 300;
callback: [:xml | self recentChartOn: xml];
with: []].

Hope this helps,

-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.

> -----Original Message-----
> From: [hidden email] [mailto:seaside-
> [hidden email]] On Behalf Of Rick Flower
> Sent: Thursday, May 10, 2007 4:12 PM
> To: Seaside - general discussion
> Subject: Re: [Seaside] Pondering if Dojo javascript toolkit ismore
> convenientthan Scriptaculous for Seaside solutions
>
> Boris Popov wrote:
> > I don't see any harm in using whatever JS toolkit that would make

your
> > life easier. Here, for instance, we use both Scriptaculous/Prototype
and

> > YUI extensively, even mixed together,
> >
> > (html anchor)
> > class: 'settings';
> > onClick: (html
> > yuipanel: editor
> > config: [:v | v close: true]);
> > with: 'Settings'
> >
> > where,
> >
> > yuipanel: component config: block
> > (self updater)
> > evalScripts: true;
> > id: 'yuipaneltarget';
> > onFailure: ((SUStream new)
> > nextPutAll: 'displayGenericError();';
> > yourself);
> > callback: [:render |
> > | dialog |
> > dialog := (Seaside.YUIPanel new)
> > immediate: true;
> > delegate: component;
> > yourself.
> > block value: dialog.
> > dialog renderContentOn: render];
> > yourself
> >
> > So it's really up to you to decide what tool is right for the job.
>
> When doing this sort of stuff (integrating a new js library w/

Seaside),
> is there any rhyme or reason as to whether certain functionality
should
> be subclassed from WADecoration vs. WAComponent, etc and perhaps more
> specifically how detailed it's "api" should be and if I should try to
> use standardized keywords where possible? I've taken Boris'
> latest (but a bit dated at this point) version of SeasideYUI and
updated
> the embedded js code for YUI, and added a first whack at yuimenu
support
> which I've got subclassed from WADecoration.. However, I'm finding
that
> the use of it is a bit verbose and it would be nicer to bury some of
the
> details in some form of an object and perhaps have it emit some of the
> nested divs,etc.
>
> I guess it might be nice to be able to do something like this -- in
the

> case of a yuimenu:
>
> renderContentOn: html
> html yuimenu id: #foo with: [
> html yuimenuitem id: #bar with: [
> html anchor callback: [ self blah ]; with: 'MyLink'
> ]
> ]
>
> My initial code currently uses lots of nested divs, unordered lists,
> list items, etc. Fairly verbose even for small menus.. Using

something
> like above would really hide a bunch of the crap behind the scenes..
> But, perhaps people want to see that stuff? Anyway, just thought I'd
> ask..
>
>
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Rick Flower

Re: Pondering if Dojo javascript toolkit ismore convenientthan Scriptaculous for Seaside solutions

Boris Popov wrote:
> In most cases where you'd like to emit this kind of thing, what you're
> really looking for is a simple subclass of WABrush, for instance I have
> a thing called ChartTag,

[ ... ]

> all of which gets used just as any other brush,
>
> (html div)
> style: 'padding-top: 0.5em;';
> with: [(html chart)
> type: (Charts flash: 'Column2D');
> size: 610 @ 300;
> callback: [:xml | self recentChartOn: xml];
> with: []].

Thanks Boris.. I was actually looking at WABrush earlier but was afraid
it wouldn't support js emission early in the game to get into the <head>
portion of the HTML document.. Right now I'm using the #updateRoot: on
my WADecoration based object to do that and it works fine.. However, I
like what you've done above much better.

P.S. Assuming I keep the backwards compatibility of the existing
SeasideYUI code, are you OK with me making updates to the existing
package on the Cincom repository? Thought I'd ask before I stepped on
any toes.. (8->
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Boris Popov, DeepCove Labs (SNN)

RE: Pondering if Dojo javascripttoolkit ismore convenientthan Scriptaculous for Seaside solutions

Go ahead, that's why its there. Unfortunately I'd moved it inside our
main development bundle since so all the most recent improvements are a
little hard to separate at the moment. I'll see if I can put together a
little "community sharing" project in early summer to get this out.
People had also expressed interest in seeing our S3 client as well as
Fusion Charts mappings released, so that would be my goal, again *if* I
can find some spare time...

-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.

> -----Original Message-----
> From: [hidden email] [mailto:seaside-
> [hidden email]] On Behalf Of Rick Flower
> Sent: Thursday, May 10, 2007 4:35 PM
> To: Seaside - general discussion
> Subject: Re: [Seaside] Pondering if Dojo javascripttoolkit ismore
> convenientthan Scriptaculous for Seaside solutions
>
> Boris Popov wrote:
> > In most cases where you'd like to emit this kind of thing, what

you're
> > really looking for is a simple subclass of WABrush, for instance I
have

> > a thing called ChartTag,
>
> [ ... ]
>
> > all of which gets used just as any other brush,
> >
> > (html div)
> > style: 'padding-top: 0.5em;';
> > with: [(html chart)
> > type: (Charts flash: 'Column2D');
> > size: 610 @ 300;
> > callback: [:xml | self recentChartOn: xml];
> > with: []].
>
> Thanks Boris.. I was actually looking at WABrush earlier but was

afraid
> it wouldn't support js emission early in the game to get into the
<head>

> portion of the HTML document.. Right now I'm using the #updateRoot: on
> my WADecoration based object to do that and it works fine.. However, I
> like what you've done above much better.
>
> P.S. Assuming I keep the backwards compatibility of the existing
> SeasideYUI code, are you OK with me making updates to the existing
> package on the Cincom repository? Thought I'd ask before I stepped on
> any toes.. (8->
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

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

Rick Flower

Re: Pondering if Dojo javascripttoolkit ismore convenientthan Scriptaculous for Seaside solutions

Boris Popov wrote:
> Go ahead, that's why its there. Unfortunately I'd moved it inside our
> main development bundle since so all the most recent improvements are a
> little hard to separate at the moment. I'll see if I can put together a
> little "community sharing" project in early summer to get this out.
> People had also expressed interest in seeing our S3 client as well as
> Fusion Charts mappings released, so that would be my goal, again *if* I
> can find some spare time...

Sounds good.. Thanks Boris!
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside