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
On Sat, 14 Dec 2002, Adrian Lienhard wrote:
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.
Adrian,
I agree with Frank that the name "Page" is a confusing one - in a web application context, page has a very strong meaning already and it's best not to overload it. But pages are also the part of your model I have trouble understanding - I think I see what you're trying to do (make the metamodel extensible to cover new types of information), but I'm not sure I like the way it's done. Instead having a #Naming page and a #Type page for each attribute, I'd rather have a single Attribute class that had 'name type' as inst vars, containing AttributeName and AttributeType objects, for example. Adding new types of information should be rare enough that inst variables could simply be added to Attribute as needed. This would do away with the nested Dictionaries in Metamodel, and would allow the Attribute class to provide more convenient ways of building up the structures - I could see having one method on Attribute for each of what you now have as "page" types, ie, #addLabel:description:, #addType:isMultiple:, or some such, that would create the appropiate objects. I also think that Attribute should probably know the selector it is describing (and these should be describing selectors, *not* inst vars), so Metamodel just becomes a simple Set of Attributes.
The way you have Fields working is interesting - not depending on the metamodel, but just loading it in as defaults. Again, I can see the logic here, but actually I think it's more useful to just say "Attribute is how you control this form, and if you want to customize it, give it a different set of Attributes". That is, right now you basically have two metamodels - the attribute and the one the form actually uses - and you translate between them. I think it's more valuable to consistently use one - for example, Field>>value now looks something like
model perform: selector
whereas if you have a decent Attribute class, it should look like
attribute valueForObject: model
which is ultimately a lot more flexible. If you keep two separate metamodels you'll either have to make them *both* that flexible (which isn't realistically gonna happen) or sacrifice the flexibility on one of them (in which case, why bother having the nice one?).
These are just suggestions, of course - you do what works best for you, and if I don't like it, I'll just write an alternate implementation :).
Avi
----- Original Message ----- From: "Avi Bryant" avi@beta4.com Sent: Saturday, December 14, 2002 10:06 PM
[...]
I agree with Frank that the name "Page" is a confusing one - in a web application context, page has a very strong meaning already and it's best not to overload it.
Yes, first I started with "AttributeSet" but then I thought that it could be missleading because it is not a kind of Set... but this might be less confusing. Anyway, renaming is no problem.
But pages are also the part of your model I have trouble understanding - I think I see what you're trying to do (make the metamodel extensible to cover new types of information), but I'm not sure I like the way it's done. Instead having a #Naming page and a #Type page for each attribute, I'd rather have a single Attribute class that had 'name type' as inst vars, containing AttributeName and AttributeType objects, for example. Adding new types of information should be rare enough that inst variables could simply be added to Attribute as needed. This would do away with the nested Dictionaries in Metamodel, and would allow the Attribute class to provide more convenient ways of building up the structures
Agreed. Maybe I wanted to be too general...
[...]
The way you have Fields working is interesting - not depending on the metamodel, but just loading it in as defaults. Again, I can see the logic here, but actually I think it's more useful to just say "Attribute is how you control this form, and if you want to customize it, give it a different set of Attributes". That is, right now you basically have two metamodels - the attribute and the one the form actually uses - and you translate between them. I think it's more valuable to consistently use one - for example, Field>>value now looks something like
model perform: selector
whereas if you have a decent Attribute class, it should look like
attribute valueForObject: model
which is ultimately a lot more flexible. If you keep two separate metamodels you'll either have to make them *both* that flexible (which isn't realistically gonna happen) or sacrifice the flexibility on one of them (in which case, why bother having the nice one?).
These are just suggestions, of course - you do what works best for you, and if I don't like it, I'll just write an alternate implementation :).
Thanks for the feedback and ideas. Actually, I would apreciate that what I'm doing can be used by others. I don't mind if you come up with an altered version and say, "look, I've changed this and this". I am quite open ;-).
Adrian
Adrian, What is the status of the metamodel code?
On Saturday, December 14, 2002, at 03:54 PM, Adrian Lienhard wrote:
----- Original Message ----- From: "Avi Bryant" avi@beta4.com Sent: Saturday, December 14, 2002 10:06 PM
[...]
I agree with Frank that the name "Page" is a confusing one - in a web application context, page has a very strong meaning already and it's best not to overload it.
Yes, first I started with "AttributeSet" but then I thought that it could be missleading because it is not a kind of Set... but this might be less confusing. Anyway, renaming is no problem.
But pages are also the part of your model I have trouble understanding - I think I see what you're trying to do (make the metamodel extensible to cover new types of information), but I'm not sure I like the way it's done. Instead having a #Naming page and a #Type page for each attribute, I'd rather have a single Attribute class that had 'name type' as inst vars, containing AttributeName and AttributeType objects, for example. Adding new types of information should be rare enough that inst variables could simply be added to Attribute as needed. This would do away with the nested Dictionaries in Metamodel, and would allow the Attribute class to provide more convenient ways of building up the structures
Agreed. Maybe I wanted to be too general...
[...]
The way you have Fields working is interesting - not depending on the metamodel, but just loading it in as defaults. Again, I can see the logic here, but actually I think it's more useful to just say "Attribute is how you control this form, and if you want to customize it, give it a different set of Attributes". That is, right now you basically have two metamodels - the attribute and the one the form actually uses - and you translate between them. I think it's more valuable to consistently use one - for example, Field>>value now looks something like
model perform: selector
whereas if you have a decent Attribute class, it should look like
attribute valueForObject: model
which is ultimately a lot more flexible. If you keep two separate metamodels you'll either have to make them *both* that flexible (which isn't realistically gonna happen) or sacrifice the flexibility on one of them (in which case, why bother having the nice one?).
These are just suggestions, of course - you do what works best for you, and if I don't like it, I'll just write an alternate implementation :).
Thanks for the feedback and ideas. Actually, I would apreciate that what I'm doing can be used by others. I don't mind if you come up with an altered version and say, "look, I've changed this and this". I am quite open ;-).
Adrian
Seaside mailing list Seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/seaside
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
Hi Derek
At the moment there are several attribute classes (such as type, naming, validationrules) which I use for my form support. I started using it for my current project and it seams useful till now. What's still open, is how to make the form enough flexible for nice custom design (but this is something else...). And of corse, the metamodel could be improved (feedbacks very wellcome!).
What would be interesting is to see how the metamodel can be used for other components. E.g. the exsiting report-component. Or maybe it could be the place to define security: Defining wich actions exsist and how the access is restricted (wasn't it you, Derek, working on something like this?).
You can finde the current source 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)
Please let me know if I should give some explanation how it works.
Btw, what is the status of your Web Calendar?
Adrian
_____________________ Adrian Lienhard www.adrian-lienhard.ch www.netstyle.ch
----- Original Message ----- From: "Derek Brans" brans@nerdonawire.com To: seaside@lists.squeakfoundation.org Sent: Tuesday, December 24, 2002 3:01 PM Subject: Re: [Seaside] Metamodel and Form support
Adrian, What is the status of the metamodel code?
On Saturday, December 14, 2002, at 03:54 PM, Adrian Lienhard wrote:
----- Original Message ----- From: "Avi Bryant" avi@beta4.com Sent: Saturday, December 14, 2002 10:06 PM
[...]
I agree with Frank that the name "Page" is a confusing one - in a web application context, page has a very strong meaning already and it's best not to overload it.
Yes, first I started with "AttributeSet" but then I thought that it could be missleading because it is not a kind of Set... but this might be less confusing. Anyway, renaming is no problem.
But pages are also the part of your model I have trouble understanding - I think I see what you're trying to do (make the metamodel extensible to cover new types of information), but I'm not sure I like the way it's done. Instead having a #Naming page and a #Type page for each attribute, I'd rather have a single Attribute class that had 'name type' as inst vars, containing AttributeName and AttributeType objects, for example. Adding new types of information should be rare enough that inst variables could simply be added to Attribute as needed. This would do away with the nested Dictionaries in Metamodel, and would allow the Attribute class to provide more convenient ways of building up the structures
Agreed. Maybe I wanted to be too general...
[...]
The way you have Fields working is interesting - not depending on the metamodel, but just loading it in as defaults. Again, I can see the logic here, but actually I think it's more useful to just say "Attribute is how you control this form, and if you want to customize it, give it a different set of Attributes". That is, right now you basically have two metamodels - the attribute and the one the form actually uses - and you translate between them. I think it's more valuable to consistently use one - for example, Field>>value now looks something like
model perform: selector
whereas if you have a decent Attribute class, it should look like
attribute valueForObject: model
which is ultimately a lot more flexible. If you keep two separate metamodels you'll either have to make them *both* that flexible (which isn't realistically gonna happen) or sacrifice the flexibility on one of them (in which case, why bother having the nice one?).
These are just suggestions, of course - you do what works best for you, and if I don't like it, I'll just write an alternate implementation :).
Thanks for the feedback and ideas. Actually, I would apreciate that what I'm doing can be used by others. I don't mind if you come up with an altered version and say, "look, I've changed this and this". I am quite open ;-).
Adrian
Seaside mailing list Seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/seaside
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
Seaside mailing list Seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/seaside
On Saturday, December 28, 2002, at 05:49 PM, Adrian Lienhard wrote:
Hi Derek
At the moment there are several attribute classes (such as type, naming, validationrules) which I use for my form support. I started using it for my current project and it seams useful till now. What's still open, is how to make the form enough flexible for nice custom design (but this is something else...). And of corse, the metamodel could be improved (feedbacks very wellcome!).
What would be interesting is to see how the metamodel can be used for other components. E.g. the exsiting report-component. Or maybe it could be the place to define security: Defining wich actions exsist and how the access is restricted (wasn't it you, Derek, working on something like this?).
You can finde the current source 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)
Please let me know if I should give some explanation how it works.
Btw, what is the status of your Web Calendar?
Adrian
Adrian Lienhard www.adrian-lienhard.ch www.netstyle.ch
----- Original Message ----- From: "Derek Brans" brans@nerdonawire.com To: seaside@lists.squeakfoundation.org Sent: Tuesday, December 24, 2002 3:01 PM Subject: Re: [Seaside] Metamodel and Form support
Adrian, What is the status of the metamodel code?
On Saturday, December 14, 2002, at 03:54 PM, Adrian Lienhard wrote:
----- Original Message ----- From: "Avi Bryant" avi@beta4.com Sent: Saturday, December 14, 2002 10:06 PM
[...]
I agree with Frank that the name "Page" is a confusing one - in a web application context, page has a very strong meaning already and it's best not to overload it.
Yes, first I started with "AttributeSet" but then I thought that it could be missleading because it is not a kind of Set... but this might be less confusing. Anyway, renaming is no problem.
But pages are also the part of your model I have trouble understanding - I think I see what you're trying to do (make the metamodel extensible to cover new types of information), but I'm not sure I like the way it's done. Instead having a #Naming page and a #Type page for each attribute, I'd rather have a single Attribute class that had 'name type' as inst vars, containing AttributeName and AttributeType objects, for example. Adding new types of information should be rare enough that inst variables could simply be added to Attribute as needed. This would do away with the nested Dictionaries in Metamodel, and would allow the Attribute class to provide more convenient ways of building up the structures
Agreed. Maybe I wanted to be too general...
[...]
The way you have Fields working is interesting - not depending on the metamodel, but just loading it in as defaults. Again, I can see the logic here, but actually I think it's more useful to just say "Attribute is how you control this form, and if you want to customize it, give it a different set of Attributes". That is, right now you basically have two metamodels - the attribute and the one the form actually uses - and you translate between them. I think it's more valuable to consistently use one - for example, Field>>value now looks something like
model perform: selector
whereas if you have a decent Attribute class, it should look like
attribute valueForObject: model
which is ultimately a lot more flexible. If you keep two separate metamodels you'll either have to make them *both* that flexible (which isn't realistically gonna happen) or sacrifice the flexibility on one of them (in which case, why bother having the nice one?).
These are just suggestions, of course - you do what works best for you, and if I don't like it, I'll just write an alternate implementation :).
Thanks for the feedback and ideas. Actually, I would apreciate that what I'm doing can be used by others. I don't mind if you come up with an altered version and say, "look, I've changed this and this". I am quite open ;-).
Adrian
Seaside mailing list Seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/seaside
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
Seaside mailing list Seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/seaside
Seaside mailing list Seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/seaside
heh. sorry for the spurious post. my wireless mouse got confused when I switched batteries and it seems to have decided to respond to this thread.
nice pattern, btw.
cheers, rob
On Saturday, December 28, 2002, at 06:26 PM, Robert Withers wrote:
On Saturday, December 28, 2002, at 05:49 PM, Adrian Lienhard wrote:
Hi Derek
At the moment there are several attribute classes (such as type, naming, validationrules) which I use for my form support. I started using it for my current project and it seams useful till now. What's still open, is how to make the form enough flexible for nice custom design (but this is something else...). And of corse, the metamodel could be improved (feedbacks very wellcome!).
What would be interesting is to see how the metamodel can be used for other components. E.g. the exsiting report-component. Or maybe it could be the place to define security: Defining wich actions exsist and how the access is restricted (wasn't it you, Derek, working on something like this?).
You can finde the current source 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)
Please let me know if I should give some explanation how it works.
Btw, what is the status of your Web Calendar?
Adrian
Adrian Lienhard www.adrian-lienhard.ch www.netstyle.ch
----- Original Message ----- From: "Derek Brans" brans@nerdonawire.com To: seaside@lists.squeakfoundation.org Sent: Tuesday, December 24, 2002 3:01 PM Subject: Re: [Seaside] Metamodel and Form support
Adrian, What is the status of the metamodel code?
On Saturday, December 14, 2002, at 03:54 PM, Adrian Lienhard wrote:
----- Original Message ----- From: "Avi Bryant" avi@beta4.com Sent: Saturday, December 14, 2002 10:06 PM
[...]
I agree with Frank that the name "Page" is a confusing one - in a web application context, page has a very strong meaning already and it's best not to overload it.
Yes, first I started with "AttributeSet" but then I thought that it could be missleading because it is not a kind of Set... but this might be less confusing. Anyway, renaming is no problem.
But pages are also the part of your model I have trouble understanding - I think I see what you're trying to do (make the metamodel extensible to cover new types of information), but I'm not sure I like the way it's done. Instead having a #Naming page and a #Type page for each attribute, I'd rather have a single Attribute class that had 'name type' as inst vars, containing AttributeName and AttributeType objects, for example. Adding new types of information should be rare enough that inst variables could simply be added to Attribute as needed. This would do away with the nested Dictionaries in Metamodel, and would allow the Attribute class to provide more convenient ways of building up the structures
Agreed. Maybe I wanted to be too general...
[...]
The way you have Fields working is interesting - not depending on the metamodel, but just loading it in as defaults. Again, I can see the logic here, but actually I think it's more useful to just say "Attribute is how you control this form, and if you want to customize it, give it a different set of Attributes". That is, right now you basically have two metamodels - the attribute and the one the form actually uses - and you translate between them. I think it's more valuable to consistently use one - for example, Field>>value now looks something like
model perform: selector
whereas if you have a decent Attribute class, it should look like
attribute valueForObject: model
which is ultimately a lot more flexible. If you keep two separate metamodels you'll either have to make them *both* that flexible (which isn't realistically gonna happen) or sacrifice the flexibility on one of them (in which case, why bother having the nice one?).
These are just suggestions, of course - you do what works best for you, and if I don't like it, I'll just write an alternate implementation :).
Thanks for the feedback and ideas. Actually, I would apreciate that what I'm doing can be used by others. I don't mind if you come up with an altered version and say, "look, I've changed this and this". I am quite open ;-).
Adrian
Seaside mailing list Seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/seaside
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
Seaside mailing list Seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/seaside
Seaside mailing list Seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/seaside
Seaside mailing list Seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/seaside
Adrian, Sorry it's taken so long to respond,
I haven't figured out a good way to keep track of threads that I've posted to or that I'm interested in. Any suggestions?
Thanks for your response. I haven't looked at the code yet but I will shortly.
I haven't made any move on security yet, but I will be in the next few days. Same with the calendar. It will get revamped in the next few days.
Regards, Derek
On Saturday, December 28, 2002, at 02:49 PM, Adrian Lienhard wrote:
Hi Derek
At the moment there are several attribute classes (such as type, naming, validationrules) which I use for my form support. I started using it for my current project and it seams useful till now. What's still open, is how to make the form enough flexible for nice custom design (but this is something else...). And of corse, the metamodel could be improved (feedbacks very wellcome!).
What would be interesting is to see how the metamodel can be used for other components. E.g. the exsiting report-component. Or maybe it could be the place to define security: Defining wich actions exsist and how the access is restricted (wasn't it you, Derek, working on something like this?).
You can finde the current source 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)
Please let me know if I should give some explanation how it works.
Btw, what is the status of your Web Calendar?
Adrian
Adrian Lienhard www.adrian-lienhard.ch www.netstyle.ch
----- Original Message ----- From: "Derek Brans" brans@nerdonawire.com To: seaside@lists.squeakfoundation.org Sent: Tuesday, December 24, 2002 3:01 PM Subject: Re: [Seaside] Metamodel and Form support
Adrian, What is the status of the metamodel code?
On Saturday, December 14, 2002, at 03:54 PM, Adrian Lienhard wrote:
----- Original Message ----- From: "Avi Bryant" avi@beta4.com Sent: Saturday, December 14, 2002 10:06 PM
[...]
I agree with Frank that the name "Page" is a confusing one - in a web application context, page has a very strong meaning already and it's best not to overload it.
Yes, first I started with "AttributeSet" but then I thought that it could be missleading because it is not a kind of Set... but this might be less confusing. Anyway, renaming is no problem.
But pages are also the part of your model I have trouble understanding - I think I see what you're trying to do (make the metamodel extensible to cover new types of information), but I'm not sure I like the way it's done. Instead having a #Naming page and a #Type page for each attribute, I'd rather have a single Attribute class that had 'name type' as inst vars, containing AttributeName and AttributeType objects, for example. Adding new types of information should be rare enough that inst variables could simply be added to Attribute as needed. This would do away with the nested Dictionaries in Metamodel, and would allow the Attribute class to provide more convenient ways of building up the structures
Agreed. Maybe I wanted to be too general...
[...]
The way you have Fields working is interesting - not depending on the metamodel, but just loading it in as defaults. Again, I can see the logic here, but actually I think it's more useful to just say "Attribute is how you control this form, and if you want to customize it, give it a different set of Attributes". That is, right now you basically have two metamodels - the attribute and the one the form actually uses - and you translate between them. I think it's more valuable to consistently use one - for example, Field>>value now looks something like
model perform: selector
whereas if you have a decent Attribute class, it should look like
attribute valueForObject: model
which is ultimately a lot more flexible. If you keep two separate metamodels you'll either have to make them *both* that flexible (which isn't realistically gonna happen) or sacrifice the flexibility on one of them (in which case, why bother having the nice one?).
These are just suggestions, of course - you do what works best for you, and if I don't like it, I'll just write an alternate implementation :).
Thanks for the feedback and ideas. Actually, I would apreciate that what I'm doing can be used by others. I don't mind if you come up with an altered version and say, "look, I've changed this and this". I am quite open ;-).
Adrian
Seaside mailing list Seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/seaside
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
Seaside mailing list Seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/seaside
Seaside mailing list Seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/seaside
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
seaside@lists.squeakfoundation.org
-
Adrian Lienhard -
Avi Bryant -
Derek Brans -
Robert Withers