seaside April 2004

seaside@lists.squeakfoundation.org

35 participants
41 discussions

Adding application to Root Component selector
by ld 26 Apr '04

26 Apr '04

I've started a new application in Seaside and set CanBeRoot to 'true' for the class. Yet, when I go to ..../seaside/config and attempt to add an entry point for the app, it is not selectable from the Root Component droplist. How do I get it to appear? Also: do my 'seaside' applications need to be created inside the 'Seaside' catetory? Or can I create my own category and place them there? -Larry Kelly

3 6

[Mewa] Can't format multipleRelationshipAttribute
by Germ�n S. Arduino 25 Apr '04

25 Apr '04

Hi: I'm developing an app using Mewa, and must to relate an item with many others that I must recover form a collection instvar of the model. Something like this, of MWPerson Example: metaobject multipleRelationshipAttribute: #interests do: [:attribute | attribute label: 'Interests'; relationshipTo: [self class interests]; addValidationRule: [:collection | collection size > 1] errorString: 'Select at least two interest items']. But i'm using relationshipTo: [MySession currentSession domainmodel interests] formatWith: [:each | each interestName, ' (' , each interestType , ')']; In my case "interests" is a collection instvar from the model (not from the class, as in the MWPerson example). Inspecting model allinstances I can see that all is correct, but the rendered data only show "aInterest" instead interestName (interestType). Also, I must add a validationRule (that check at least one interest selected), that dont't works neither. Any help will be appreciated. Regards. gsa.

2 4

Re: Seaside 2.5 and XML
by Avi Bryant 23 Apr '04

23 Apr '04

On Apr 23, 2004, at 6:16 AM, Torsten Bergmann wrote: > To check the output of a simple test component I've looked at > the source of the generated HTML. Since it was not well indented > I copied it to XMLSpy to automatically indent the file. For future reference - toggle halos, and try the [S] link at the right hand side of the halo bar of the part of the page you're interested in. > XMLSpy told me that the > output is not well formatted XML. The problem is that all links > Seaside generates > contain a & sign which has a special meaning in XML and has to be > translated to & to get valid xml. > > <foo bar="&"/> is not valid xml, but <foo bar="&"/> is. > > Changing the Seaside output to valid XML in the future may help > testing it using > XML Parsers and Unit Frameworks. Thanks - I hadn't run into this before. It seems like a common issue. For example, see http://www.mezzoblue.com/archives/2003/02/17/urls_vs_xhtm/ . I'll fix it. Avi

1 0

Stupid question(s) of the month
by Eduardo Di Santi 22 Apr '04

22 Apr '04

Im really new in Seaside (its really awesome). Is there any way for me to change the <head> tag in a WAComponent ? Also ... Is there any way to use my own css file. Thanks. Eduardo

2 1

Appearance of tools in 2.5a
by C. David Shaffer 21 Apr '04

21 Apr '04

In mozilla 1.5 under linux the close button on the tools (like the Profiler) seems to look a bit "off" vertically. The l in the word "close" extends upwards into the grey title region but the rest of the word is not in the grey title region at all. In 2.3 I think the entire close link was in the title secion, wasn't it? Any suggestions on how I could get it back there? This is, of course, a mission critical issue ;-) David -- C. David Shaffer http://www.cs.westminster.edu/~shaffer http://www.shaffer-consulting.com

2 3

FW: About seaside
by Pennell, David 21 Apr '04

21 Apr '04

Stéphane Ducasse posted this to the VisualWorks NC list and asked me to forward it to the Seaside list. -----Original Message----- From: stéphane ducasse [mailto:ducasse@iam.unibe.ch] Sent: Wednesday, April 21, 2004 4:22 AM To: VWNC Subject: About seaside hi guys the presentation of lukas of seaide was really good. http://renggli.freezope.org/personal/work/ I discussed with other seaside programmers (ian prince and also michel bany) and I want share some important points. - My boss was thinking that seaside could be a killer app for smalltalk but there are still some stuff to do :) (he was one of the first one to build a search engine for the www even before mosaic came out). - Now some facts: one french editor mentioned that the books on java .net were just really low as all the books in language the last two years except the ones on PhP. I think that creating a 50 pages tutorial on using seaside to build application for the PhP programmer could be really a hit (my plate is full but I would do it else). I think that it would be a smart move of the community to think about that. Because soon other languages will have continuation (perl 6 apparently) so we should do some stuff now. We discussed with Michel Bany and he said that a port of seaside was under way but I forgot to ask if the port will be freely available after. What is important to realise is that seaside is one way to have people developing application in Smalltalk because the seaside part should be max 20% of the application and the rest is Smalltalking.....So I'm sure that you are all busy but there is an opportunity there Smalltalk miss the internet so may be we should pay attention to not miss it another time. Stef

2 1

2.5 docs part I: the render tree
by Avi Bryant 21 Apr '04

21 Apr '04

I promised more detail on the changes in Seaside 2.5; here's a first installment. This may, in fact, be too much detail - it'll be hard slogging for casual users. If you find any of it too obtuse ("but how do we *use* this stuff?"), just let me know. But I wanted to at least get some info out there. Since we're still in alpha, this is all subject to change, yada, yada. Note: ASCII diagrams included, so best viewed in a monospace font... Avi ------- The current state of the UI of a Seaside application is represented by a tree of WAPresenter instances. The root of this tree is held onto by the current WARenderLoop. The render loop spins in a tight loop, iterating once for each response/request pair. Each iteration involves walking the tree several times, for these purposes: 1. Updating the current URL. Any presenter in the tree may wish to append extra information to the current URL, either to make bookmarks more meaningful when revisted in the future (once the current session state has disappeared), or to affect behavior in the present (eg, by adding fragments to the URL that refer to named anchors in the current document). In this pass, each presenter will be sent #updateUrl:, and passed an instance of WAUrl. Most presenters will not take advantage of this, which is fine, and so the default implementation is empty. There was no direct equivalent to this pass in Seaside 2.3, although WASession>>addToPath: was used for more or less the same purpose. 2. Rendering content to the response. The actual message sent to each item in the tree is #renderWithContext:, which is passed a WARenderingContext, but this is a fairly low level method, and probably won't need to be overridden. In its default implementation, it creates a new renderer around the context (usually WAHtmlRenderer, but overridable via #rendererClass), and sends #renderAllOn: passing the renderer as an argument. This, in turn, sends #renderContentOn:, which is the method that most presenters will override, and which should be familiar to users of Seaside 2.3. 3. Processing the request. This is actually two passes, #processRequestInputs:context: and #processRequestActions:context:. Each gets passed in a WARequest and a WARenderingContext as arguments. By default, each presenter extracts from the rendering context any of the callbacks that it caused to be registered during #renderContentOn:, and then invokes any that appear in the request. #processRequestInputs:context: only invokes value callbacks (for form inputs, etc), whereas #processRequestActions:context: invokes action callbacks, from links and submit buttons. This ensures that all of the values are set before any actions occur. In Seaside 2.3, all of the callbacks were processed at once, rather than by the individual items in the tree. This change makes it possible for items in the tree to control the request processing of items below themselves, for example by wrapping a special exception handler around them (useful for validation, eg), or by preventing them from processing the request at all (useful for authentication and similar). To easily enable this kind of thing, both request processing passes go through #processRequest:do:, which takes the WARequest as its first argument and the block as its second. The default implementation simply evaluates the block, which then continues the walk down the tree; overriders may put conditional evaluation around evaluating it based on the request, or evaluate it inside an exception handler, etc. See WATransaction or WABasicAuthentication for examples. The tree is a somewhat unusual "shape". The skeleton is made up of instances of WAComponent, a subclass of WAPresenter. Each of these must implement the #children method, which returns a (possibly empty) collection of its subcomponents. In the simplest case, walking the tree is simply a depth first traversal: from the root component, through its children, recursively to their children, and so on. However, this basic case can be extended in two ways. The first is by "decorating" components. Each WAComponent can have any number of instances of WADecoration (another subclass of WAPresenter) attached to it. When walking the tree, all of a component's decorations are visited before it is. This means that, for the purpose of tree traversal, a component is "below" its decorations: they can render content that encloses it, or affect its request processing. At the implementation level, a WAComponent has a (possibly unused) pointer to its first (outermost) decoration. Decorations have a "next" pointer to the next decoration or, for the last/innermost decoration, to the component itself. So a simple tree might look like this: x ------> y ----> z -- | next next | decoration | | next | | root --------> A <------------------- | child | | | child | C B The root has two children, A and B. A has one child, C, and B has none. A also has three decorations, x, y, and z. The traversal will be in this order: (root, (x, y, z, A, (C)), (B)). The most important thing to note about this is that A's decorations get visited *before* A itself does. Also note that, as indicated by the parentheses, A and C are both "controlled" by the x-y-z decorations, whereas the root and B are not. The second way the tree is extended is a special case of the first, which is through delegation. When a component is sent #call: with another component, it adds a special WADelegation decoration with the new component referenced as the "delegate". WADelegation is unusual in that it adjusts the tree traversal to follow the "delegate" pointer instead of the "next" pointer. This means that, for as long as that decoration is present, the component being decorated and all of its children will be obscured by the delegate - they won't appear in any tree traversals. When the delegate is sent #answer:, the Delegation decoration is removed and the original component becomes visible again. So, adding a delegation "d" with a component "D" to the above tree, we would get: delegate x ------> y -------> d ----------> D | next next | | | next | | decoration | z | | next root --------> A <------------------- | child | | | child | C B The traversal order is now (root, (x, y, d, D), (B)). Nothing "under" d (including the decoration z and the components A and C) will get rendered. However, x and y, which are before d in the decoration list, do get visited (and have control over D and its children). Why are x and y before d, and z after? It's up to the individual decoration. Some decorations (usually those that affect request processing, rather than those that render content) will wish to stay active during delegation, and some will not. Those that wish to come before delegations in the chain should implement #isGlobal to return true.

1 0

swapping root components
by radoslav hodnicak 19 Apr '04

19 Apr '04

Currently I'm playing with iframes and it is convenient to store the session's root component in a state holder instead of the instvar. This way all the iframes work within the same session and have own root components - set on the fly. This is useful to create print previews etc too. The changes to seaside (2.3) were minimal and so far it's working ok, any bad surprises that could wait for me? Regards, radoslav -- pgp.mit.edu 0x30DEBAE6 12EE FED5 D5B1 77ED 5637 EB77 2A5F 22F9 30DE BAE6

2 1

seside 2.5a questions
by ld 19 Apr '04

19 Apr '04

I'm learning seaside, starting with Version 2.5a. It seems the best way to learn is to ask questions, so here goes: 1) WACounter initialization. What does registerObjectForBacktracking: self. actually do? 2) When would I use: # registerAsApplication method? Should it be used for embedded components? or for only those where #canBeRoot is true? 3) WACounter. Does #children need to be defined as follows? children ^ counter 4) WACounter: if I add a #step variable to hold the rate of change, would #childern become: children ^ #('counter' 'step') Thanks for you patience. -Larry Kelly

3 2

Upgrading to 2.5a-avi.3
by Samuel Tardieu 17 Apr '04

17 Apr '04

After an upgrade to SeaSide 2.5a-avi.3, the only URL I can visit is /seaside/config. Any other (my application and the examples) gives me back: | Internal Server Error | MessageNotUnderstood: UndefinedObject>>application: | | Comanche/6.2 (unix) Server at localhost Port 9090 without any debug link that I could use to trace it. Sam -- Samuel Tardieu -- sam(a)rfc1149.net -- http://www.rfc1149.net/sam

4 11

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

seaside April 2004