seaside March 2008

seaside@lists.squeakfoundation.org

76 participants
97 discussions

Cincom is looking for a Smalltalk/Seaside Developer
by James Robertson 08 Mar '08

08 Mar '08

I hope this message is not "out of bounds" for this list, but here goes: Cincom is in the process of hiring some new developers to join our Smalltalk development team - in particular, we are looking for a Seaside developer. Interested? Please send an email to employme(a)cincom.com , and reference position #3015 Thanks! James Robertson http://www.cincomsmalltalk.com/blog/blogView Talk Small and Carry a Big Class Library

2 2

Stop event for parents, not local callback
by Sebastian Sastre 08 Mar '08

08 Mar '08

Hi there, simplifying the real example, I have an anchor A inside a div. This div is child of its parent container B (also a div with some other children). I've hooked #click event in the B container (it makes a request to remember state and some effect which affects all those children). Right now when A is clicked it does its own full render and callback. But also B is getting the click event and reacting whith its own click hook, which is not desired to happen. Thats because of event bubling and Prototype's Event.stop() is supposed to help in such cases. The problem is, so my question, how can stop bubbling of the click event of the anchor (so the parents wont see it) and at the same time do not kill the anchor's full render callback action? Anchors seems to need bubbling to make their actions? Exists a way to use onClick: and have the same effect of a "traditional" Seaside anchor callback with full render? thanks, Sebastian Sastre

1 0

GNU Smalltalk 3.0a released including Seaside support
by Paolo Bonzini 07 Mar '08

07 Mar '08

GNU Smalltalk 3.0a is now available from ftp://alpha.gnu.org/gnu/smalltalk/smalltalk-3.0a.tar.gz This is the first release of GNU Smalltalk including support for Seaside. A simple tutorial is available at http://smalltalk.gnu.org/blog/bonzinip/seaside-development-gnu-smalltalk (it guides you through loading Seaside and developing a Counter-like component). The Seaside packages are based on Seaside-Core-lr.59.mcz and they run on top of Swazoo 2.1. Thanks to Dale Heinrichs, Philippe Marschall, Janko Mivsek, Lukas Renggli for help with porting Seaside and Swazoo to GNU Smalltalk! Paolo

2 1

[Election 2008] All answers collected in the Q&A, and 32 HOURS LEFT TO VOTE!
by goran＠krampe.se 07 Mar '08

07 Mar '08

Hi all Squeakers! I just added Andrew's and Edgar's answers (in the nick of time!) to the Q&A swiki page: http://wiki.squeak.org/squeak/6029 It is a long page, but if you want to get a grip on the candidates IMO it is quite useful. Now... it's only circa 32 hours left to vote (if I calculated it correctly) and we have: - 435 authorized voters that have been sent ballots. - 153 votes so far! The first number is good but the second is scary. People, remember to VOTE before time runs out! regards, Göran PS. If you are registered on SqP (people.squeakfoundation.org) with a ranking Apprentice or higher AND have a correct email in that account - you SHOULD have received a ballot. If you haven't - then email me in private and I will help you.

2 1

Design of WAComponent(s)
by stephan＠stack.nl 07 Mar '08

07 Mar '08

Philippe wrote: > The points you made IMHO apply only if you want to build a component > library or even component framework. That should be an addon protect > and has no place in Seaside-Core. Honestly I have my doubts if such a > such thing could ever work given the very special needs of users > concerning not only functionality but also mark up. -1 There are lots of situations where the user needs the functionality now and doesn't care too much how it looks. Customizing is all very nice but takes lots of time & money. There should be something like Seaside-Core-Widgets. First-time users should not have to download multiple projects to get started. Groetjes, Stephan

3 2

Design of WAComponent(s)
by Andreas Tönne 06 Mar '08

06 Mar '08

Hello! Inspired by my own work needs on Seaside 2.8 on VisualWorks 7.6 and also by the recent discussion on MVC vs. Seaside I like to start a discussion about forming a generalization of components, giving them more inner structure and more uniformity. A more detailed model of WAComponent. Possibly there are projects running in the Squeak world that I do not know of and that make this discussion unnecessary. In that case I would be grateful for any pointers! To illustrate where I am coming from, let me pick one of the predefined components in the core: WATree. I picked this component because it is generally useful (a typical element of web applications) and because it supports my ideas nicely. The class comment says " WATree implements a tree menu, which supports nesting, collapsing and expanding. Prefixes items with "+/-" to indicate items that can be expanded/collapsed." If you look at the implementation then you see that it has several fundamentally different tasks: - provide a tree fascade over an arbitrary object - manage the selection in this tree model - manage the tree expansion/collapse model of the tree - create the XHTML presentation of the tree model - (indirectly) provide controller behavior by letting you place callbacks in the select: block Also the view part is rather inflexible in the XHTML generated: it builds an unordered list with constant css classes for the elements. I am an old school Smalltalker who values clear models and responsibilities. When I looked at this component, my first thought was "this is a bit much for one class" and the second one was "what is exactly the intended responsibility of components?". Add that you cannot have two trees on a page with different appearance (style) without some work, involving code duplication. If we split this class into independent concepts that can be recombined/varied in useful ways then we get: - a model of a tree - a model of the visual appearance (expand/collapse) of the tree model - a XHTML generator = a domain logic combining the above three with selection and interface to the application logic (callback) One can put the collapsed/expanded information into the domain logic object, which means a new WATree model will be constructed from a tree model and a matching XHTML generator. How is this useful? - stays object-oriented on the model side by encapsulating the tree model instead of exposing it in blocks - allows different renderings of such tree expansion state. Unordered lists of buttons, labels and associated children are fine but one option - allows more configuration control on the styles attached (ok this could be a simple useful addition to WATree in its current shape too) - when modeled right it allows to share XHTML rendering among components Interestingly, the shore components example has its own, rather differently implemented tree component with a dedicated model of the visual tree appearance and using tables instead of unordered lists. So by not providing the developer with a Seaside Component Framework, a lot of unnecessary development work and code duplication is taking place. I think the message to new developers should be "pick a component and configure it to your needs" instead of "look at the examples and program one for yourself". So what do you think? Is there a project/plans in this direction? Did I violate the principles of Seaside? Andreas -- Andreas Tönne Lead Consultant Cincom Systems GmbH & Co. oHG Tel.: +49 6196 9003 100 Mobile: +49 172 6159272 Fax: +49 6196 9003 270 Geschäftsführer/Managing Directors: Thomas M. Nies, Gerald L. Shawhan oHG mit Sitz/based in Schwalbach/Ts. (Amtsgericht Königstein/Ts. HRA 2653) Pers. haftender Gesellschafter/Partner liable to unlimited extent: Cincom Systems Verwaltungsgesellschaft mbH (Amtsgericht Königstein/ Ts. HRB 5069)

10 27

WAResponce, XML response and BOM
by Petr Fischer 06 Mar '08

06 Mar '08

Hi, I am using Seaside with FusionCharts. XML data file for FusionCharts is generated by this code: url := (html urlForAction: [ self session returnResponse: (Seaside.WAResponse new contentType: 'text/xml'; nextPut: 239 asCharacter; nextPut: 187 asCharacter; nextPut: 191 asCharacter; nextPutAll: chart xmlString; yourself) ]). 239, 187 and 191 characters is BOM mark for UTF-8 (EF BB BF) - but this 3 characters are messed in responce to "C3 AF C2 BB C2 BF" - what is wrong? Thanks very much for suggestions, Petr Fischer (VW7.6dev, mac os x)

4 3

Re: [Seaside] Design of WAComponent(s)
by Boris Popov 06 Mar '08

06 Mar '08

Ah, but widgets are different from components. Widget may be a date picker and component may be a login prompt. I'm all for having widgets so long as their markup is well designed not to interfere outright with peoples work, but I can't see components being general enough to be useful, those you build up yourself as pieces of your application. Cheers! -Boris (via BlackBerry) ----- Original Message ----- From: seaside-bounces(a)lists.squeakfoundation.org <seaside-bounces(a)lists.squeakfoundation.org> To: Seaside - general discussion <seaside(a)lists.squeakfoundation.org> Sent: Thu Mar 06 08:52:52 2008 Subject: Re: [Seaside] Design of WAComponent(s) Stephane, thank you for getting my point. ;-) All, I found the various objectives for Seaside hiding behind the answers very interesting. No offense please but some answers show a lack of appreciation for the users of Seaside. If you want to grow the users base of Seaside, you need to answer the question of Microsoft. If you dont, it will remain a great tool from specialists for specialists. And fade in oblivion eventually. Let me get some points about my objectives straight (because some jumped to conclusions). 1. I do not look at a "one-framework-fits-it-all" approach. I know the limitations of a pluggable design for components. It is extremely hard! (designing Smalltalk applications for 21 years should qualify me to say that) Particularly the mixing of structure, presentation and interactivity in one XHTML structure limits the configuration choices for a general framework alot. (but I see a value in getting there half way) 2. I agree that the core should be small and needs some cleanup (and commenting please). Having said that, please think about this statement of Stephane for a minute: > I do not have the skills and time of lukas to create widgets from scratch. > But I imagine that I should be able to reuse them. Chapeau! That *IS* the main point. Those non-specialist that might be attracted to Seaside and Smalltalk are very likely not fluent in the details of XHTML, Java-script and AJAX. Asking them to create new components from the given examples will end in bad copy&paste programming. One interesting point is the size or specialization of predefined components. A login component is indeed not very interesting for a predefined component. Individual widgets that need to be pieced together from primitive HTML and AJAX elements are much more promising. These *expected* elements for UI design are pretty much standard and hence open for a standard implementation. I shoot for 80:20. I like to catch 80% of the standard widgets and components and let 20% be custom implementations. Andreas Am 06.03.2008 17:21 Uhr schrieb "stephane ducasse" unter <stephane.ducasse(a)free.fr>: > Hi sebastian > > I still see the point of andreas. > I would love to have a usable report widget in which I can plug other > components. > I already sent that a while back but once I show Seaside to a guy at > microsoft. > He was impressed then after 3 min he asked me how many widgets are > ready to use. > And he was right. > > There are no incompatibilities between seaside as it is now and a cool > widgets set. > Having a cool widgets set with basic but fully working widgets would > be a big plus: we could > prototype even faster our applications. I do not have the skills and > time of lukas > to create widgets from scratch. But I imagine that I should be able to > reuse them. > > Stef > > > On Mar 6, 2008, at 5:10 PM, Sebastian Sastre wrote: > >>> -----Mensaje original----- >>> De: seaside-bounces(a)lists.squeakfoundation.org >>> [mailto:seaside-bounces@lists.squeakfoundation.org] En nombre >>> de Philippe Marschall >>> Enviado el: Miércoles, 05 de Marzo de 2008 17:25 >>> Para: Seaside - general discussion >>> Asunto: Re: [Seaside] Design of WAComponent(s) >>> >>> 2008/3/5, Andreas Tönne <atoenne(a)cincom.com>: >>>> .... >>> >>> I think the main point to understand here is that the components that >>> come with Seaside are not a component library or even a component >>> framework. They are simple stand alone components. They are not made >>> with reusabilty, configurabitlity or customyzability in mind. They >>> are >>> focused on KISS and "getting the job done" and mostly for use Seaside >>> itself. They will get you started fast but at one point sooner rather >>> than later you will hit their limits. That's ok, they're not supposed >>> to be the "be all, end all". >>> >>> The points you made IMHO apply only if you want to build a component >>> library or even component framework. That should be an addon protect >>> and has no place in Seaside-Core. Honestly I have my doubts if such a >>> such thing could ever work given the very special needs of users >>> concerning not only functionality but also mark up. >>> >>> Cheers >>> Philippe >>> >> >> Quoting you: >> "...They are not made with reusabilty, configurabitlity or >> customyzability in mind..." >> >> Quoting Seaside site: >> "About >> Seaside provides a layered set of abstractions over HTTP and HTML >> that let you build highly interactive web applications quickly, >> reusably and maintainably. >> ..." >> >> Note that *reusably* is the second *bold* word after quickly. >> >> And also (from same source): >> "...Embedded components. Stop thinking a whole page at a time; >> Seaside lets you build your UI as a tree of individual, stateful >> component objects, each encapsulating a small part of a page. Often, >> these can be used over and over again, within and between >> applications - nearly every application, for example, needs a way to >> present a batched list of search results, or a table with sortable >> columns, and Seaside includes components for these out the box..." >> >> So? >> >> Sebastian >> >> _______________________________________________ >> seaside mailing list >> seaside(a)lists.squeakfoundation.org >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> > > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside -- Andreas Tönne Lead Consultant Cincom Systems GmbH & Co. oHG Tel.: +49 6196 9003 100 Mobile: +49 172 6159272 Fax: +49 6196 9003 270 Geschäftsführer/Managing Directors: Thomas M. Nies, Gerald L. Shawhan oHG mit Sitz/based in Schwalbach/Ts. (Amtsgericht Königstein/Ts. HRA 2653) Pers. haftender Gesellschafter/Partner liable to unlimited extent: Cincom Systems Verwaltungsgesellschaft mbH (Amtsgericht Königstein/ Ts. HRB 5069) _______________________________________________ seaside mailing list seaside(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

1 0

[OT] Sea-stars Wallpaper
by Torsten Bergmann 06 Mar '08

06 Mar '08

see http://cleanwallpapers.blogspot.com/2007/07/sea-stars.html Have fun, Torsten -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/?mc=sv_ext_mf@gmx

1 0

WAUploadTest
by Sigrid E. Mortensen 06 Mar '08

06 Mar '08

Hi, I have discovered that there are some files for which WAUploadTest (and, more significant to me, my application, part of which was built based on this example) will not work. From the Functional Seaside Test Suit, Upload tab, after first clicking the Chose File (or Browse) button and selecting one of these files, and then clicking the Load button, the entire area under the tabs goes blank, including the 'Upload File' heading. Furthermore, putting a halt into the callback reveals that the callback is not even being called for these files. The files in question are .pdf files. Other .pdf files will work. The files that don't work are perfectly happy to open in Adobe Photoshop or Adobe Reader. I am using Seaside 2.8, currently at version 2.8a1-mu.540. I have tested this in both Safari 3.0.4 and Firefox 1.0.3, with the same results. Any ideas? Thanks in advance, -- Sigrid.

2 1

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

seaside March 2008