ismore convenientthan Scriptaculous for Seaside solutions
boris at deepcovelabs.com
Thu May 10 23:21:13 UTC 2007
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,
size := 100 @ 100.
type := Charts flash: 'Column2D'.
callback := [:xml | ]
| div |
div := canvas div.
canvas script: ('var chart<1s> = new FusionCharts("<2s>",
"mychart<1s>", "<4p>", "<5p>", "0", "0"); chart<1s>.setDataURL("<3s>");
add: div ensureId;
add: (canvas absoluteUrlForResource: type);
add: (URI encode: (canvas urlForCharts: callback) allowed: '');
add: size x;
add: size y;
^self brush: ChartTag new
^self chart with: aBlock
all of which gets used just as any other brush,
style: 'padding-top: 0.5em;';
with: [(html chart)
type: (Charts flash: 'Column2D');
size: 610 @ 300;
callback: [:xml | self recentChartOn: xml];
Hope this helps,
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
boris at deepcovelabs.com
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
> -----Original Message-----
> From: seaside-bounces at lists.squeakfoundation.org [mailto:seaside-
> bounces at lists.squeakfoundation.org] On Behalf Of Rick Flower
> Sent: Thursday, May 10, 2007 4:12 PM
> To: Seaside - general discussion
> convenientthan Scriptaculous for Seaside solutions
> Boris Popov wrote:
> > I don't see any harm in using whatever JS toolkit that would make
> > life easier. Here, for instance, we use both Scriptaculous/Prototype
> > 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/
> is there any rhyme or reason as to whether certain functionality
> 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
> the embedded js code for YUI, and added a first whack at yuimenu
> which I've got subclassed from WADecoration.. However, I'm finding
> the use of it is a bit verbose and it would be nicer to bury some of
> 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
> 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
> 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
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
More information about the seaside