seaside December 2002

seaside@lists.squeakfoundation.org

19 participants
26 discussions

seaside with mod proxy: mapping urls to applications
by Derek Brans 17 Jan '03

17 Jan '03

How do you map urls to WAApplications with mod proxy? ProxyPass /seaside http://127.0.0.1:8000/seaside ProxyPassReverse /seaside http://127.0.0.1:8000/seaside That works, but if I want to map /calendar to a seaside application: ProxyPass /calendar http://127.0.0.1:8000/seaside/sandcaster ProxyPassReverse /calendar http://127.0.0.1:8000/seaside/sandcaster doesn't work... You would expect it to load www.mydomain.com/calendar/4;123412094209374 (sample session id) but instead, apache is looking for www.mydomain.com/seaside/sandcaster/4;123412094209374, which it can't find. thanks, Derek Nerd on a Wire: Web and Information Solutions Website Design - Database Systems - Site Hosting 604.874.6463 mailto:info@nerdonawire.com For more information, visit http://nerdonawire.com

6 17

WebDVS Package
by Derek Brans 12 Jan '03

12 Jan '03

Here's an implementation of DVS on Seaside (idea by Avi) It's useful for managing code on a remote server. It is limited to filing in and filing out changesets from the default directory. Minimally tested (I used it to file itself out). Derek Nerd on a Wire: Web and Information Solutions Website Design - Database Systems - Site Hosting 604.874.6463 mailto:info@nerdonawire.com For more information, visit http://nerdonawire.com

3 4

Metamodel and Form support
by Adrian Lienhard 03 Jan '03

03 Jan '03

Hi all So, the moment has come where I would like to have your critical oppinion! There are two parts: The metamodel (a model which describes your actual domain model) and the form support which now depends on the metamodel. The leading idea is that a metamodel which has to be defined only once, delivers the neccesary information to the components. I'll first show a simple example how it works and then try to go a little more into how it is implemented. A part of the metamodel definition may look like this: page := WANamingAttributePage new label: 'ATextLabel'; description: 'some description'; yourself. Metamodel addAttributePage: page forInstvar: #text. or: page := WARelationshipTypeAttributePage new beMultiple; ownerObjectBlock: [WASession currentSession domainmodel]; collectionSelector: #teamMembers; yourself. Metamodel addAttributePage: page forInstvar: #responsiblePeople. When creating the form this information is used to name the fields, to create the right input tags, to populate select lists, to assign validation rules etc. To create a form you subclass WAForm (Avi, I tried to change this to compositioning. But it makes things more complicated and less stright forward) and overwrite initializeFields: textfield _ WATextField on: self model for: #text. textfield loadAttributePagesFrom: metamodel. self addField: textfield. or much simpler: add all your fields to the form at once with one single statement ... form addFields: #(#text #responsiblePeople #number #date ) with: metamodel. ...and you have a fully working form! Is this not cool? Metamodel: A metamodel (instance of WAMetamodel) describes one domain model class. All the description is separated into "attribute pages". The metamodel can contain global pages and pages for each instvar. A attribute page is a subclass of WAAttributePage. In the above example I used WARelationshipTypeAttributePage (better names?) which describes a instvar "of type relationship". Each page has a name which makes it easier to access a page. (e.g. "metamodel attributePage: #Type forInstVar: #responsiblePeople"). I did this "page-apporach" because like this, the attributes (or whatever will be stored in the pages) can be spearated into semantic units. (Naming, Type, ValidationRules etc.). You only add pages which willl be needed by your components. Form: The class WAForm manages all Fields. A Field (the unit for label, description, input type,..) is responsible for loading, cashing, committing (Avi, I don't use the proxy anymore) and validating data. Each field holds the required meta information which can be loaded from a metamodel (loading just sets all found attributes in the field). This makes it enough flexible to manually alter information after loading the metamodel or not use the metamodel at all. What to be done next: - Additional Attribute pages (type: text, number, boolean, date, .. rules: ... sorting/filtering: ...) - Factor out the rendering of form and field. - Support for radio groups and multiple-select lists. There is one basic example: WAFormExample (in the Form-Test category) There are Unit-Tests for the form support Source can be downloaded here: http://www.adrian-lienhard.ch/files/squeak/Seaside-Metamodel.st http://www.adrian-lienhard.ch/files/squeak/Seaside-Form.st http://www.adrian-lienhard.ch/files/squeak/tableRowWithFix.cs (#tableRowWith:with: had a tiny bug) So, if you have read all this, you might be interested in it ;-). I'd like to hear what you think about it. What could be done better? Does it go in the right direction? Is it usable? What is missing? Adrian _____________________ Adrian Lienhard www.adrian-lienhard.ch www.netstyle.ch

4 7

Seaside 2.07 and config passwords
by Nevin Pratt 03 Jan '03

03 Jan '03

I've just started playing with Seaside again, having left off back when it was at version 0.94. Back in the 0.94 days, the 'config' app could be password protected, via IAAuthenticatedSession>>authenticateUser:password: How do you password protect the current 'config' app? It's a little dangerous to present a working Smalltalk Browser to the world from within their web browser (i.e., the 'classes' app), and even if you remove it, they can add it back in if they can access the 'config' app. So, what's the easy way to lock this thing down for presentation to the world? Furthermore, I personally prefer the default installation to be a "locked-down" installation. Otherwise somebody could install this thing in their Squeak image, put their image on the web without checking Seaside security, and from there they are toast. Nevin

2 5

monticello remote repositories
by Derek Brans 31 Dec '02

31 Dec '02

Is the current version of Monticello able to do remote repositories? If so, how do you set it up (I have everything installed xml-rpc, comanche, etc but I don't know how to run Monticello as a server). thanks. Nerd on a Wire: Web and Information Solutions Website Design - Database Systems - Site Hosting 604.874.6463 mailto:info@nerdonawire.com For more information, visit http://nerdonawire.com

6 18

2.1 preview
by Avi Bryant 30 Dec '02

30 Dec '02

Hi all, I've put an early release of Seaside 2.1 up at http://beta4.com/seaside2/Seaside2.10.st.gz . The main change in this release is that the old ManagedObject/IVAP method of instrumenting instance variable reads and writes is no longer used. Instead, it introduces an explicit stateTree instance variable which is used by components to read and write state that needs to rewind and fork for the back button. Although you could directly use stateTree #at: and #at:put:, subclasses of WAComponent now also have an extra line in their class definition which allows you to declare stateVariableNames. Accessors which go through the stateTree will be generated for each of these names. For example, WAComponent subclass: #WACounter instanceVariableNames: '' stateVariableNames: 'count ' classVariableNames: '' poolDictionaries: '' category: 'Seaside/Examples-Basic' generates count ^stateTree at: #count count: anObject stateTree at: #count put: anObject This change does raise the question of when it's appropiate to use stateVars instead of instVars. When in doubt, it never hurts to make something a state variable (except for increased memory usage...). As a rule of thumb, however, if you ever change the value of an instance variable *after* the component is first created and initialized, then it should probably be a stateVar. Going through my own code, I found it interesting how few instance variables this applied to... I'm hopeful that making this distinction more explicit will lead to a better understanding of mutation patterns in general. I'd appreciate it if people tried this out and let me know how they found the new approach. Cheers, Avi

4 11

Seaside 2.13
by Avi Bryant 29 Dec '02

29 Dec '02

Hi all, A new release of the experimental 2.1 version of Seaside is now available at http://beta4.com/seaside2/downloads/Seaside2.13.st.gz . Although this uses the same StateTree mechanism for managing backtrackable state as previous 2.1 releases, the interface to it has changed. Rather than directly sending #at: and #at:put: messages to a StateTree instance, components can now obtain a StateHolder from the session (through WASession>>stateHolder). This has the same protocol as ValueHolder, but will update its #contents properly during backtracking. Hopefully this is enough more convenient than the direct StateTree usage that the custom class definition template and auto-generated accessors in earlier versions of 2.1 are now unnecessary. Feedback desired, as always. Avi

3 3

url's... towards multi-section multi-domain seaside
by Derek Brans 23 Dec '02

23 Dec '02

I'm still a little hung-over from 1/2 price beer at Yaletown Brewing Company last night... so excuse any incoherence... As I mentioned earlier, I'm working on a site that's mostly html but has a couple of sections that I want to use seaside for. The seaside sections should remember a user once they've logged in. I want the ability to pass variables into an application via the url... this "hard-coded" url would only be used to reconfigure an application to a different state Potentially I want to be able to host more than one domain from a single squeak process. I think this is a design that I will use often in my web development, I'm looking for a good way to handle it. So, here's an example url: http://somedomain.com/calendar I want to mod proxy that to: http://127.0.0.1:8000/somedomain.com/calendar where somedomain.com is the name of the application responsible for the sections in that domain. I want seaside to keep sending me to somedomain.com/calendar, so long as I'm in the calendar section in order to make the url look consistent. Now, what if I want to take them directly to a particular event on the calendar? http://somedomain.com/calendar?id=business%20meeting I need to implement this functionality. Don't know how hard it will be. The hardest problem right now is getting mod-proxy to behave well with Seaside without requiring a baseURL like "seaside"... hmmm. I suppose I could get somedomain.com application to respond "http://somedomain.com/sectionName" when queried for it's application base url. Implementing the notion of "section", which seems well-defined at the moment, is another challenge. Any comments? Thank you, Derek Nerd on a Wire: Web and Information Solutions Website Design - Database Systems - Site Hosting 604.874.6463 mailto:info@nerdonawire.com For more information, visit http://nerdonawire.com

1 0

GOODS object removal
by Swanlund, Glenn 20 Dec '02

20 Dec '02

I was playing with GOODS and added the object 'foo' as shown in the Quick Start section of the GOODS Swiki. Anybody know how to remove this object from the database? Glenn

2 1

Re: [Seaside] Metamodel and Form support
by Frank Sergeant 14 Dec '02

14 Dec '02

"Adrian Lienhard" <adi(a)netstyle.ch> wrote: > A part of the metamodel definition may look like this: > page := WANamingAttributePage new > label: 'ATextLabel'; > description: 'some description'; > yourself. > Metamodel: > A metamodel (instance of WAMetamodel) describes one domain model class. All > the description is separated into "attribute pages". The metamodel can > contain global pages and pages for each instvar. A attribute page is a > subclass of WAAttributePage. In the above example I used > WARelationshipTypeAttributePage (better names?) First, let me say that I *like* the general approach. However, my initial reaction to the use of the term "page" for this purpose was rather negative. I feel it overloads the idea of "web page" but with a drastically different meaning. So, I am hopeful that a better term can be found. I don't know what the best term would be, but perhaps "attribute set" or "attribute description" or "rendering guide category" would be closer to expressing the essence. -- Frank

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

seaside December 2002