Re: New Member with a question.

Most Seaside applications don't require you to write much controller
functionality. The hard work is done behind the scenes by the Seaside
callback handlers. As Philippe writes, the small controller methods
are usually combined with the view (subclass of WAComponent). Usually
method categories are used to keep view and controller code apart, by
convention these categories are named #rendering and #actions.

Lukas

On Fri, Nov 21, 2008 at 3:47 PM, Philippe Marschall
<philippe.marschall <at> gmail.com> wrote:
> 2008/11/21 Tony Giaccone <tony <at> giaccone.org>:
>> Hi,
>>
>> Just thought I would introduce myself. I'm new to this group, and very
>> interested in Squeak and Seaside. I'm a 30 year veteran of computer wars.
>> Having first started programming in 1977 in APL in high school. Now, I'm a
>> professional developer, have worked all over the US and in Europe and
>> develop web applications in Java. I started out using WebObjects and am now
>> using a variety of horrible J2EE frameworks.
>>
>> After 30 years of TPS rreports and corporate manuvering, I'd pretty much
>> lost my interest in development. It had become just a job. The horrible
>> movement back in time from WebObjects to J2EE didn't help the situation.
>>  Squeak and Seaside have piqued my interest in developing again. In a way
>> that I haven't felt in a long time. So I'm very interested in best
>> practices.  I'm hoping that if I can develop a good enough grounding in this
>> stuff that I can suggest we try Seaside as a development platform where I
>> work.  I have my fingers crossed.
>>

PlotKit in Gemstone

hi, I forgot to report this, it's a very stupid thing, but I think it's 
worth fixing.

When I imported PlotKit into Gemstone (to use with Seaside, of course) I 
had a small problem:

PKScriptLibrary >> #mochiKitJs has a very long String, apparently longer 
that what's supported for literals in Gemstone. The very simple solution 
for me was to cut the string in two, adding '+' roughly inthe middle.

In my case I cut it just before the line rading:

MochiKit.Base.update(MochiKit.Async.{evalJSONRequest:function(){

(it's the only appearance of evalJSONRequest:function in the code.

    I think it'll be a great idea to fix this in the repository, and 
with it, PlotKit can be directly loaded from squeaksource into Gemstone.

    otherwise dale offered to host the project in Gemstone Monticello 
server, but I think it doesn't make any sense to replicate it.

    richie

PS: I haven't loaded all SeaChart, juts PlotKit, PlotKitLibrary and 
SeaChart. Examples seem to work :)

Re: Re: Seaside 2.9a1 release

_______________________________________________
seaside mailing list
seaside <at> lists.squeakfoundation.org
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

How to plug Seaside with a server

_______________________________________________
seaside mailing list
seaside <at> lists.squeakfoundation.org
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Re: ANN: Seaside 2.9a1 release

_______________________________________________
seaside mailing list
seaside <at> lists.squeakfoundation.org
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Re: ANN: Seaside 2.9a1 release

2008/11/17, Lautaro Fernández <evaklo <at> gmail.com>:
> 2008/11/15 Philippe Marschall <philippe.marschall <at> gmail.com>
>
>> 2008/11/11, Lautaro Fernández <evaklo <at> gmail.com>:
>> > Hi,
>> >
>> > 2008/11/9 Julian Fitzell <jfitzell <at> gmail.com>
>> >
>> >> [...]
>> >> A more complete list of change and new features can be found at
>> >> http://seaside.st/community/development/seaside29
>> >>
>> >
>> > That page (under Modularization) says the following:
>> >
>> > [...]
>> >
>> > It allows for smaller Seaside installations. For example you can have
>> >> Seaside without the tests or without Kom and use Swazoo 2 instead.
>> >
>> > [...]
>> >>
>> >
>> > This mean that just a few changes need to be made in order to get a
>> working
>> > Swazoo-Seaside server?
>>
>> It means no changes need to be made. Swazoo 2.1 is supported out of
>> the box (well in theory at least, in practice it has only been tested
>> on Squeak).
>>
>> > Could you tell me a place to see a how-to use this modularity in order
>> > to
>> > make the port of Swazoo to work with Seaside?
>>
>> To get everything working in Squeak you need to:
>> - open an "empty" Squeak image doesn't have Seaside, Sport or Swazoo
>> loaded
>> - drag and drop the attached file over the Squeak window
>> - select "fileIn entire file"
>> - if a debugger opens telling you that instance variables start with a
>> lower case letter hit proceed
>> - when everything is done evaluate
>>  WASwazooAdaptor startOn: 8080
>> - go to http://127.0.0.1:8080/seaside/tests/alltests
>>
>
> All ran OK, except to save the image. The WASqueakPlatfrorm (class) does not
> understand the method "withName:withPriority:fork:", which is called from
> the CTPusher(classs)>>startUp. I commented that part and the where no more
> troubles anymore.

Right, I forgot to add Comet-Squeak-Core.

> About the first seaside-2-9-0a1.cs that Julian had attached, I keep getting
> an error if I tried to load it on a fresh Squeak 3.9 image.
> Internal Server Error
> MessageNotUnderstood: WAKom>>dispatchRequest:
>
> I'm loading it wrong? (this didn't happened to me on last Thursday)

Nope the script is wrong. It should load Seaside-Core-jf.320. It's
probably time to publish an alpha2 script.

>> If you open the Monticello Browser from the world menu you'll see a
>> lot of Seaside-*, Javascript-*, Scriptaculous-*, RSS-* and JQuery-*
>> packages that make up Seaside. Everything that has no -Squeak- in the
>> package name should load directly into VW. Everything that has a
>> -Squeak- in the package name has to be reimplemented (only if you want
>> it of course). However most parts can probably be salvaged either from
>> the existing 2.8 port or the Squeak implementation.
>
>
> Good to know, thank =]
>
>
>> Cincom supports Seaside so it's probably best to talk to them.
>
>
> The main problem is that they will port (or made it avaible) Seaside 2.9 for
> the next realise (which will be in US summer), but now we need to work with
> Swazoo instead of Opentalk-Http (which does not support streaming responses
> quite well).
> But I'll try again to see if they can give me a workaround.

Ok, let's to for another round. The attached change set contains the
very latest code from yesterday evening. It has seen only very little
testing. It loads almost everything including both Comanche and Swazoo
because we only implemented Comet on Comanche.

However the Seaside Control Panel now seems to work. You'll find it in
the world menu under tools.

Cheers
Philippe

_______________________________________________
seaside mailing list
seaside <at> lists.squeakfoundation.org
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Seaside 2.9 & dynamic variables

Has 2.9 changed how it does dynamic variables to some form of thread-local 
variables? If so, does that mean I can stop in the debugger and see those 
variables more easily? In 2.8 they were often visible through session, which 
was not accessible in the debugger.

Thanks! 

Some insight please

Hi,
i'm working with Seaside 2.8.2.
In WARegisty>>#unregisterExpiredHandlers at the end of the method it reads: 
  [expired do: [ :each | each unregistered ]] fork.
In turn, WASession>>#unregistered reads like: 
  super unregistered.
  self expire.

So why do expired sessions are sending #expire to theirselves again?
Is there a design reason behind that?

This makes my override MyAppWASession>>#expire to be called twice.
(i explicitly expire my sessions by sending #expire to them but that
doesnt change anything, does it?)

Is it ok if i just override WASession>>#unregistered to not send
expire again?

Greets,
-- vagy

Deployment How-To - Seaside, Apache, Reverse Proxy, Server environment

Hi list,

After one year of abstinence from Smalltalk I had the chance to enter
the land of web development with Seaside again. It came up that I had to
take care of deploying a web app on a virtual server. After collection
all the information from different sources I decided to write a How-To.

It handles installing Squeak in a Linux environment and setting the
apache as a reverse proxy for the Seaside app. I believe for the most of
you this is nothing new but I wanted to write it down anyway and decided
to do it in my blog. Perhaps it will be helpful for some newcomers, too.

Here is the link:
http://peter-osburg.ehstpro.de/2008/11/11/deploying-squeak-on-a-virtual-server-with-linux/

Best regards,
Peter

General subclassing question with regards to callbacks...

Hi all...

I'm stumped once again -- it's probably just another ST thing that is  
throwing me for a loop..
Anyway, I've got a generic 'edit/add' widget that shows a list of  
records and then depending
on the personality selected (by the parent menu), it invokes either  
the vanilla 'add' class
to draw the form for a new record OR we render the 'editSelector'  
class who squirrels away the 'clickBlock'
for later (in case the user clicks/selects a particular user).  So, my  
initialize method and friends for the
EditSelector class looks like :

EditSelector>>initialize
	super initialize.
	userSelector := Admin_User_RecordSelector on: self.
	userEditor   := Admin_User_EditExecutor on: self.
	self userSelector clickBlock: [ : each |
		self userEditor user: each.
		self call: self userEditor.
	].

EditSelector>>renderContentOn:  html
	html render: userSelector.

While the above 'clickBlock' is valid, how its used elsewhere is not.  
See use of onClick:
below and above.. I would like to be able to determine once the user  
presses on
a row to select that user and perform an operation on them (whether it  
be delete or edit).
Anyway, the clickBlock which will handle the task portion of it is  
failing indicating that
the wrong argument count was specified (expects 1, got 0).  Any ideas?  
Hope this makes
sense!

-- Rick

Admin_User_RecordSelector >>initialize

	super initialize.
	clickBlock := nil.
	columns := OrderedCollection new
		add: (WAReportColumn selector: #familyId title: 'Family ID');  
"selector gets performed on your data item"
		add: (WAReportColumn selector: #nameLast title: 'Family Last Name ');
		yourself.

Admin_User_RecordSelector >>renderContentOn:  html

	"Get the current list of users to show..."
	self rows: (self users).
	html break.
      html paragraph class: 'legend_lookalike'; with: 'Select a Family  
to Edit - click on a family name'.
	super renderContentOn: html.

Admin_User_RecordSelector >>renderRowNumber: index item: row on: html

	"Override the onClick: method to do what we want..."
	html tableRow id: 'row' , index asString;
		class:  (self classForRowNumber: index);
		script: (self componentScriptOn: index);
		 onClick: [ self clickBlock ];
		with: [columns
				do: [:ea | self
						renderColumn: ea
						row: row
						on: html]]

Autocompleter is not working

Hi list,

I have a problem with the autocompleter. While I am using exactly the
same implementation like the SUAutocompleteTest, I can't get it to work.
My component is inherited from an SUComponent and I am using the exact
same render methods like in the test. The only difference: I am using a
WATask.

Does anybody know any problems regarding the autocompleter? I am using
the latest seaside, as well as scriptaculous versions.

Regards,
Peter