Hi,
I am a newbie to programming and especially Smalltalk/Seaside/Pier.
I've been fuddling around for a while trying to learn more in a
Smalltalk environment that is not exactly set up for *complete*
newbies like me. So with that in mind I thought I would start
collecting all the information I can into one place to help others
who may (foolishly! ;) ) follow me. This might be a bigger
undertaking than I realise just yet - but I'm game to give it a shot.
My sense is that there is a quiet group of people out there wishing
this was already available.
Here is the situation - I am not exactly sure the best way to start.
I have books (I've started with SQEAK - A Quick Trip To Objectland)
and more that I've downloaded from the web. But when it comes to Pier
and Seaside (I know this is a Pier list so we can focus on that
specifically) there is not a lot of help for people in my shoes - and
I've heard this cry elsewhere. For example, even though I'm committed
to learning Smalltalk, is Pier even ready for a non-programmer yet?
So I have set up a website @ http://www.BeatTheDrums.org where I
will start to place all the information I gather or create. I am
currently reading a lot of Lucas Renggli's writings and trying to
grok them :). With his kind permission I will be taking what I learn
from that and re-formating it (in a format that works for novices - I
want to be clear that I am showing no disrespect for his work) and
adding in everything else I discover from this list and elsewhere on
the web. The site itself is in extreme ALPHA right now as I try to
get my head around everything and find a starting point and a way to
structure my "journey".
So, on the advice of Lucas, I am announcing my intentions to the list
(sticking my head out!) and asking for your suggestions and advice.
Lucas did mention that most of you are programmers and not inclined
to document your experiences - so whatever pearls you throw my way
are welcome.
Perhaps I should start with a direct question - If you were a
complete novice how would you approach getting started on Pier, given
that you have no access to any professional Smalltalk education
(schools, classes or user groups).
Thanks
Paul
Hi Niall,
this is great news, thanks a lot for this effort. I will update the
web-site of Pier.
FYI: I also forwarded your mail to seaside(a)lists.squeakfoundation.org
(the Seaside mailing list) and smallwiki(a)iam.unibe.ch (the
Magritte/Pier mailing list).
> Set and Dictionary equality
> ==================
This is a portability problem I should know from Seaside and
Scriptaculous. I must admit that I didn't pay attention to that in
Magritte/Pier.
> 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.
Please give me a list of methods that rely on Set/Dictionary equality,
so that I can fix the code in Magritte/Pier. I guess it would be
easier to make the code more portable than having the porters to patch
these methods?
> 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.
Indeed, a well known problem, that should be easily fixable in Squeak
as well. I assume that I can find all the occurrences of this problem
by looking at the senders of #sort: ?
> 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.
Mhh, another thing I should know. I will fix it as well.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
---------- Forwarded message ----------
From: Niall Ross <niallfr(a)btinternet.com>
Date: Sep 24, 2007 4:56 PM
Subject: [ANN] Port of Pier to VW
To: vwnc(a)cs.uiuc.edu
Cc: mbany(a)cincom.com, seaside-dev(a)lists.squeakfoundation.org,
renggli(a)iam.unibe.ch, nfr(a)bigwig.net
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
Dear All,
I have been using magritte with MySql for a while. Today I discovered
that something more than basic type coercion is needed for writing
values described by MASingleOptionDescription's to the database, since
the type is defined its #reference: .
This led me to finally understand why MAStringWriter and MAStringReader
are implemented as visitors.
So... I figured that the task of coercing data types into and out of
databases is going to be a common problem, and so I have begun a
framework for doing this (properly?).
http://source.lukas-renggli.ch/magritteaddons2 -- since magritteaddons
is still inaccessible (lukas?)
The basic scheme so far is to define visitor based reader/writers for
database interfaces to use for coercion.
These reader/writers are not instanciated for every value read/written,
but may last the lifetime of a query (or longer) according to how the db
interface makes use of them.
For efficiency they also cache a single string reader and a writer for
frequent re-use.
I have also included a MAPriceDescription for good measure.
I have got a fair bit of higher level stuff working with MySQL, but I
suspect that it is not yet generic enough to be part of this framework yet.
I have also posted my version of the MySql Driver which has been hacked
up a bit to handle both mysql versions > 4.1 and < 4.1
If anyone finds this useful or would like to contribute their infinite
db know-how please let me know.
best regards
Keith
I am attempting to add labels to an MASingleOptionDescription.
as in:
descriptionImprintChooser
^MASingleOptionDescription new
auto: 'imprint';
options: [ PRCurrentContext value currentUserImprints ]
asDynamicObject;
propertyAt: #labels put: [ ... build a dictionary here ... ]
asDynamicObject;
label: 'Imprint';
priority: 140;
bePersisted;
yourself
however I suspect that an addition of "yourself" is needed for this to work:
MAOptionDescription-labelForOption: anObject
self propertyAt: #labels ifPresent: [ :labels |
labels /yourself/ at: anObject ifPresent: [ :value |
^ value ] ].
^ self reference toString: anObject
Instead I chose to implement the above by supplying a selector whch can
be performed on the object to obtain its label...
labelForOption: anObject
self propertyAt: #labelSelector ifPresent: [ :selector |
^ anObject perform: #labelSelector ].
self propertyAt: #labels ifPresent: [ :labels |
labels yourself at: anObject ifPresent: [ :value |
^ value ] ].
^ self reference toString: anObject
cheers
Keith
Hi,
I have an Object which has descriptions for:
Route
- name
- text
- track
- locations
I need to edit track and locations at the same time. That
means I want to have a componentclass for those two fields.
Usually this would be an extra object containing of those
two. But I like to avoid to build an extra class just to
be able to edit the fields separate.
Is there a way to arrange the descriptions to accomplish
that? I tried to build two subsets of the Route descriptions
(name, text) and (route,track). But it isn't possible to
add the one container to the other, or is it?
thanks in advance,
Norbert
I am reading Lukas book Magritte – Meta-Described Web Application
Development.
I have tried to type in the code and run it.
But it doesn't run. :(
DateDescription selector: #birthday label: 'Birthday')
between: (Date year: 1900) and: Date today;
yourself.
This is in the latest squeak-dev image.
It complains that DateDescription doesn't exist and offers
MADateDescription instead. Okay.
But then #year: isn't a method in Date either. :(
It would be nice if Pier/Magritte/Seaside had current documentation.
Would it be possible, reasonable to put up an OO.org doc or some such of
the original book so that it could be kept up to date by the community?
I know this is asking a lot. But I also hate to ask Lukas to do all of
the work by himself.
I don't know exactly what would be the best process for community
stewardship over material like this. But it would be nice if we had an
excellent place to start. And I think this book is. It would be nice if
it was current with the current favored images.
If this isn't doable for whatever reason, I certainly respect Lukas'
wishes concerning his material and authorship. Next best thing until a
different book or such material came out would be an excellent errata
page for this book.
Lets make choosing Squeak/Seaside/Pier as easy as possible.
Any way, some thoughts for consideration.
Thanks.
Jimmie
I find
MAWriter-visitReferenceDescription: anObject
self visitElementDescription: anObject
should that be?
MAWriter-visitReferenceDescription: anObject
self visitElementDescription: anObject reference
Keith
I guess I am gifted at breaking things. It appears that the Tag Cloud
treats tags with hyphens in as separate words.
I am not sure if this is a standard Tag Cloud-ism
Keith
