seaside-dev September 2007

seaside-dev@lists.squeakfoundation.org

15 participants
23 discussions

Seaside2.8a1-mb.487
by Philippe Marschall 02 Oct '07

02 Oct '07

Hi If I see correctly the fix to #asFilename: means we send #asString to a Symbol instead of #displayString. May I ask why? This is against our convention that all conversion to strings must be done with #displayString. We went through a lot of pain because #displayString is supposed to be working on VW contrary to #asString. Cheers Philippe

6 12

Fwd: [Seaside] [BUG] and potential fix
by Philippe Marschall 29 Sep '07

29 Sep '07

Hi I just wanted to bring this one to everyones attention, it is mainly targeted at porters. This is a bug in the server adapter so make sure your server adapter doesn't suffer from it. Cheers Philippe ---------- Forwarded message ---------- From: Vagelis Savvas <vagy(a)freemail.gr> Date: 19.09.2007 00:46 Subject: [Seaside] [BUG] and potential fix To: seaside(a)lists.squeakfoundation.org Hi, this is my first message to the list. I'm Vagelis Savvas and i'm evaluating Seaside 2.8 as fetched from SqueakSource repository (Seaside2.8a1-lr.484) on Squeak 3.8 The bug i'm talking about shows up when you have a multiselect form element (WAMultiSelectTag) on a multipart form. Regardless of how many list entries someone selects, after posting the form, the callback block parameter refers to one only of the selected list entries. To see the bug in action just accept the following code in a component: renderContentOn: html html form multipart; with:[ html multiSelect list: (OrderedCollection with: 'first' with: 'second' with: 'third'); callback: [ :value | self halt ]. html button text:'post']. select more than one list entries, post and observe value on halt. The potential fix (i call it potential coz i'm not sure if its right) lies in WAKom>>processMultipartFields: The last line of this method reads like aRequest postFields at: chunk fieldName put: contents and with the fix it reads like: (aRequest postFields at: chunk fieldName ifPresent: [ :c | c add: contents]) ifNil:[ aRequest postFields at: chunk fieldName put: (OrderedCollection with: contents)]] If the fix is wrong what else can be done about it? Greetings, vagy _______________________________________________ Seaside mailing list Seaside(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2 3

[ANN] Port of Pier to VW
by Niall Ross 27 Sep '07

27 Sep '07

A first port of the Pier CMS framework from Squeak to VW is in the Cincom open repository: It prereqs Porting-Namespaces (any version should be OK) and requires compatible versions of Magritte and MagritteForVisualWorks (anything with '...CS12.NFR...' in the version name should be OK). This version ports Pier-Model-lr.150.mcz 24 April 2007 9:28:18 pm Pier-Seaside-lr.147.mcz 28 March 2007 10:04:08 Pier-Tests-lr.69.mcz 24 April 2007 9:25:44 Pier-Security-lr.80.mcz 24 April 2007 10:27:20 I will now get the latest Squeak version and port its changes likewise. The parent version holdes a raw port of the unmodified code (with 'broken' blessing level as it will not work in VW, nor load very well). The child version holds the corresponding VW-ized code. See the blessing comments for port details. I mention some points here to invite discussion. Handling duplicate class names ===================== Where Squeak and VW have duplicate class names (e.g. Date, Color or Time) that Seaside needs, the Seaside port creates subclasses of the preferred class in the target namespace, i.e. in Seaside, to get the correct resolution. With Magritte and Pier both importing Seaside, and other namespaces being added, this seemed to demand a plethora of same-name subclasses, one for each case in each new Squeak-importing namespace, so I am trying a new approach which has worked OK for me in other cases. I have made Magritte and Pier into FirstFoundNameSpaces (see Porting-Namespaces package) and reordered their imports so that the desired resolution of any clash is the one first found. This avoids both sides of the choice of either creating spurious subclasses or make spurious simpleName-to-fullName changes in ported code. (With some minor additions, not yet published, it also makes it a lot easier to load untransformed Squeak - or other single-namespace dialect - code into VW and get correct resolution of all superclass names in class definitions and of all class names in extension methods.) The point is that code from a single namespace dialect necessarily had the same resolution of each name, so a target VW namespace that offers each preferred resolution as the first-found one in all cases is always possible. (DefaultPackageNamespaces must be used in *-Extensions packages to get correct resolutions in extension methods.) Comments welcome re whether this is useful - while porting - in general . Set and Dictionary equality ================== (This must surely have been raised before, but my attempts to find relevant past posts in any appropriate list have drawn a blank.) Some Pier test assertions rely on Squeak's implementation of equality for Dictionaries and Sets, which also checks if their contents are equal. In VW, Dictionary and Set equality do not check equality of contents. Someone porting such code cannot provide the Squeak implementations as extensions since the base VW image does not like this, producing 'memory emergency' on various operations: I deduce that some VW Dictionaries and Sets have contents whose equality tests create circularities with this. I've therefore added Set>>=@ and Dictionary>>=@ to provide the Squeak implementations, as the easiest way to edit the failing assertions. I chose =@ thinking the @ would suggest 'is equal at (its various contents)'. I made it binary only because that makes it a little less work to rewrite the tests than with a keyword method. Comments welcome, both in general and re my choice of method name. Trivial common coding style remarks ======================== Most points are already known from Seaside and other ports. One that did not arise in Seaside or Magritte AFAIK is that sort/sort: returns the sorter, not the sorted collection, in VW so needs code like ... := ... sort ... changed to ... := ... sort ... ; yourself Writing sort-in-place code this way in Squeak would make for commonality when porting is expected. Since VW's class-side #raiseSignal is already common to both it and Squeak (or already ported to Squeak), I've used it to replace the #signal method (that it calls in Squeak) in Pier code, rather than add #signal to VW. Yours faithfully Niall Ross

1 1

Seaside2.8a1-lr.492
by Philippe Marschall 26 Sep '07

26 Sep '07

I can not find Seaside2.8a1-lr.491 in the repository. Can you check if you committed it to a different repository? Cheers Philippe

2 1

Decorators and DNU
by Roger Whitney 25 Sep '07

25 Sep '07

There are two decorators, WAFormDecoration & WAWindowDecoration, that send non-standard messages to the next item in the decorator change. This means that both of those decorators must decorate a component directly. Not clear if one would want to use both decorators on the same component. However one could eliminate any such conflicts by having the WADecoration class forward any message it does not understand to the next item in the decorator chain. Anyone see any problems in doing this? ---- Roger Whitney Department of Computer Science whitney(a)cs.sdsu.edu San Diego State University http://www.eli.sdsu.edu/ San Diego, CA 92182-7720 (619) 583-1978 (Cell) (217) 390-6012

2 1

Seaside2.8a1-rew.490
by Philippe Marschall 25 Sep '07

25 Sep '07

I don't know what to say man. Seriously, I'm speechless. So many so good comments. Keep it up. Thanks again Philippe

4 3

Re: [Seaside-dev] Porting RSRSS2 in VW
by Alan Knight 25 Sep '07

25 Sep '07

Heh. Clearly, I should learn to edit the prefix before posting. I blame lack of sleep :-) At 11:05 AM 9/25/2007, Alan Knight wrote: >Does this seem reasonable to post? > >At 03:33 AM 9/25/2007, Philippe Marschall wrote: >>> > - includes some GLORP integration >>> > >>> Eventually, yes. That will hopefully be reasonably transparent to the >>> Seaside framework. >> >>So there hasn't happened anything here yet in terms of integration? Is >>that supposed to be VW-only or do you plan to port that to other >>dialects as well? > >There are a number of things done at what I'd consider the experimental level - we're still trying to figure out what the appropriate things to do are. Actual integration as far as Seaside probably wouldn't be very complicated. You'd need to have a mechanism by which you can get access to a glorp session, and it might be desirable to be able to tie in transaction boundaries with Seaside operations. More extensive is trying to figure out what are good APIs by which people can use the facilities, and making it easier to do things without writing out explicit metadata any more than necessary - what I've been calling either GlorpActiveRecord or HyperActiveRecord. I spoke at some length on some of these things at ESUG recently. It's published in the public Store, but as I said, a lot of it is experiments in figuring out what's appropriate to do, rather than finished code. > >I doubt that we would port it to other dialects ourselves, but it is, and I expect it to remain, available for other people to do so. At least that's the way Glorp ports in general have worked to date. > >>So there won't be any kind of special server-y, limited product that >>directly competes with the web edition of Gemstone/S? > >As Jim Robertson posted earlier, yes, there's likely to be a server-focused product. I don't know if you'd consider it directly competing with Gemstone or not. Having it as a separate product, if it happens, would be primarily for purposes of streamlining the user experience, particularly for people who aren't already Smalltalk users. We are looking at this as an opportunity to reach out to the broader community. At some level it competes with Gemstone (as do any of the server-related things we've done over the past decades) but that would be very low on our list of priorities. I like to describe it that the Smalltalk community is a few people in a small lifeboat on a very large ocean, and that we are much better off rowing than trying to hit each other with the oars. > > >-- >Alan Knight [|], Cincom Smalltalk Development >knight(a)acm.org >aknight(a)cincom.com >http://www.cincom.com/smalltalk >_______________________________________________ >seaside-dev mailing list >seaside-dev(a)lists.squeakfoundation.org >http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev -- Alan Knight [|], Cincom Smalltalk Development knight(a)acm.org aknight(a)cincom.com http://www.cincom.com/smalltalk

1 0

Re: [Seaside-dev] Porting RSRSS2 in VW
by Alan Knight 25 Sep '07

25 Sep '07

Does this seem reasonable to post? At 03:33 AM 9/25/2007, Philippe Marschall wrote: >> > - includes some GLORP integration >> > >> Eventually, yes. That will hopefully be reasonably transparent to the >> Seaside framework. > >So there hasn't happened anything here yet in terms of integration? Is >that supposed to be VW-only or do you plan to port that to other >dialects as well? There are a number of things done at what I'd consider the experimental level - we're still trying to figure out what the appropriate things to do are. Actual integration as far as Seaside probably wouldn't be very complicated. You'd need to have a mechanism by which you can get access to a glorp session, and it might be desirable to be able to tie in transaction boundaries with Seaside operations. More extensive is trying to figure out what are good APIs by which people can use the facilities, and making it easier to do things without writing out explicit metadata any more than necessary - what I've been calling either GlorpActiveRecord or HyperActiveRecord. I spoke at some length on some of these things at ESUG recently. It's published in the public Store, but as I said, a lot of it is experiments in figuring out what's appropriate to do, rather than finished code. I doubt that we would port it to other dialects ourselves, but it is, and I expect it to remain, available for other people to do so. At least that's the way Glorp ports in general have worked to date. >So there won't be any kind of special server-y, limited product that >directly competes with the web edition of Gemstone/S? As Jim Robertson posted earlier, yes, there's likely to be a server-focused product. I don't know if you'd consider it directly competing with Gemstone or not. Having it as a separate product, if it happens, would be primarily for purposes of streamlining the user experience, particularly for people who aren't already Smalltalk users. We are looking at this as an opportunity to reach out to the broader community. At some level it competes with Gemstone (as do any of the server-related things we've done over the past decades) but that would be very low on our list of priorities. I like to describe it that the Smalltalk community is a few people in a small lifeboat on a very large ocean, and that we are much better off rowing than trying to hit each other with the oars. -- Alan Knight [|], Cincom Smalltalk Development knight(a)acm.org aknight(a)cincom.com http://www.cincom.com/smalltalk

1 0

Porting RSRSS2 in VW
by Kogan, Tamara 25 Sep '07

25 Sep '07

An attempt to read the page contents http://www.squeaksource.com/rsrss/ gives me malformed XML document from our XML parser. (The close tag for li was not found) I am wondering if there is any intention to fix it. Thanks, Tamara Kogan Smalltalk development, Cincom Systems

5 9

Re-2: [Seaside-dev] Diagramms for using in Seaside
by Frank Urbach 25 Sep '07

25 Sep '07

I apologize. As you mentioned it was fully the wrong list. Cheers, Frank -------- Original Message -------- Subject: Re: [Seaside-dev] Diagramms for using in Seaside (25-Sep-2007 15:10) From: Lukas Renggli <renggli(a)gmail.com> To: frank.urbach(a)schmees.com > I think you might want to ask this question to > > seaside(a)lists.squeakfoundation.org > > This developer mailing list if for core-developers and people that > port Seaside to other dialects. > > Lukas > > On 9/25/07, Frank Urbach <frank.urbach(a)schmees.com> wrote: > > > > > > Hi list, > > > > for a part of our information system I would like to give seaside a try. So > > what I'm searching for are some diagrams e.g. gauges. I have found the work > > of phillip marschall in seachart (plotkit). > > Any hints are appricate. > > > > Thanks in advance > > > > Cheers, > > Frank > > > > Edelstahlwerke Schmees GmbH > > > > > > > > > > Geschäftsleitung Clemens Schmees > > > > Sitz D-01796 Pirna > > > > Handelsregister Dresden HRB 54 > > > > E-Mail: es.la(a)schmees.com > > > > WEB: www.schmees.com > > > > > > > > Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte > > Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail > > irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und > > vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte > > Weitergabe dieser Mail ist nicht gestattet. > > > > This e-mail may contain confidental and/or privileged information. If you > > are not intended recipient or have received this e-mail in error, please > > notify the sender immediately and destroy this e-mail. Any unauthorized > > copying, disclosure or distribution of the material in this e-mail is > > stictly forbidden. > > _______________________________________________ > > seaside-dev mailing list > > seaside-dev(a)lists.squeakfoundation.org > > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev > > > > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > _______________________________________________ > seaside-dev mailing list > seaside-dev(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev Edelstahlwerke Schmees GmbH Geschäftsleitung Clemens Schmees Sitz D-01796 Pirna Handelsregister Dresden HRB 54 E-Mail: es.la(a)schmees.com WEB: www.schmees.com Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidental and/or privileged information. If you are not intended recipient or have received this e-mail in error, please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is stictly forbidden.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

seaside-dev September 2007