Hi,
> I'm relatively new to Squeak, but discovered the framework you have
> built, and it appears to be useful for a project I'm working on.
> Documentation is very sparse, however, and I would like to
> volunteer to assist in developing further documentation. As a
> matter of fact, I believe Pier might be the basis for the
> documentation. I would also like to do several screencasts to
> illustrate the documentation in a tutorial fashion. I know some of
> your time will be required to guide me and review the
> documentation, but if you would consider my offer, I believe it
> might lead to wider usage of Seaside/Magritte/Pier..
sounds like an interesting project. Depending on what kind of
documentation you would like to build it could be a good match. The
documentation you find in the appendix of my master thesis [1] has
been generated from class and method comments using Pier and exported
as Latex. One could also build a Pier Web site.
I would suggest that you subscribe to the Pier mailing-list at [2]
and ask further questions there.
Cheers,
Lukas
[1] http://www.iam.unibe.ch/~scg/Archive/Diploma/Reng06a.pdf
[2] https://www.iam.unibe.ch/mailman/listinfo/smallwiki
--
Lukas Renggli
http://www.lukas-renggli.ch
Following Chris' advice to implement a read strategy, I thought I would
give it a go.
In the first stages of optimising Magma to serve pier pages.
the figures are pretty bad without a readStrategy. I put a test
'information' page page 10 levels down the url path, and following a
rendering of that page we get the last item in the log at:
*401 [14141] Read(100) *'<b>Test Suites:</b> Pier is heavily tested.
There are more than 1000 ...etc...
*402 [14147] Read(101) *'</td></tr></table>'
That is 101 proxy materialisations in 14.1 seconds. If you add the 10
seconds that it takes to obtain a MagmaSession (in the non-shared
WAMagmaSession) then that is a long time to wait for a web page.
(WAMagmaSharedSession is pre-cached).
not so good!
After carefully implementing a readStrategy
The final lines of the log now look like this!
*312 [311] Read(3) *a PRDocument
...
...
*367: [335] (7/7/8) PRText-text = '<b>Test Suites:</b> Pier is heavily
tes...etc...*
That is 3 reads, which take ~30-80ms to apply the read strategy and
~100ms to fetch from magma, each. Since the final read has not actually
happened at the time of this last log item, I make that roughly 430ms to
retrieve everything in this test page.
The first read retrieves the whole path skeleton in one hit (not
entirely necessary)
The second read retrieves the 'environment' document which pier uses as
its display and style template. The third read retrieves the desired
document, again in one hit.
In practice it is likely that the 'path skeleton' and the 'environment'
will remain cached in memory, so in general use, 100-150ms, to serve
a page from Magma to Pier isnt bad going especially as compared to the
non-optimised results.
Keith
p.s. this is on a 700Mhz Pentium 3 machine with old slow 10G disk drives.
Oh. Just found an August email from Lukas...
So perhaps to use forms we point to the forms code on his site...
http://mc.lukas-renggli.ch/pier/
I'll try it. Correct me if I'm wrong.
Thanks,
Patrick
========
I need some clarification on forms in Pier. From a search I get the impression that the forms code is already in the Pier source. I installed whatever is in SqueakMap but unless I'm overlooking it, I don't think the forms code is installed with the Pier install. I also don't see how to start using forms from the Pier user interface, so more evidence it may be absent.
What's the "official" word before I start keyboarding the code myself?
Thanks,
Patrick
I need some clarification on forms in Pier. From a search I get the impression that the forms code is already in the Pier source. I installed whatever is in SqueakMap but unless I'm overlooking it, I don't think the forms code is installed with the Pier install. I also don't see how to start using forms from the Pier user interface, so more evidence it may be absent.
What's the "official" word before I start keyboarding the code myself?
Thanks,
Patrick
I am just getting started with Magritte and/or Pier. The goal is to edit some fairly lengthy form-like objects: people, property, and transactions involving those things.
not knowing much this feels very Pier-like, with each of these created in a form-based editor and links among them.
On the transaction side there is a need to send subsets of these things off to other sites and systems, and then create new related things from the results, e.g. "proposals" and so on.
So as I understand the tools, Magritte would be good to describe these things and Seaside would be good for the transactional user interfaces. Just HTTP and HTTPS would be used on the back end of the transactions.
How well would Pier fit in here? i.e. creating the objects in Pier and then having some Seaside and other code refer to those objects, formatting them for HTTP methods.
On the back end of the transactions I'd want to parse the incoming information and create Pier objects from those.
Reasonable? Easy? Any suggesttions?
Thanks,
Patrick
Howdy,
I have released the first version of a Web-based UI for creating,
editing, and removing user from Pier (based on Lukas Renggli's Pier-
Security package.)
The project is available at:
http://www.squeaksource.com/PierSecurityManager.html
This is my first Smalltalk program and I'd welcome feedback on the
code. Specifically, I'm coming to Smalltalk via Ruby, Java, C++, and
Objective-C. I am very sure I haven't found my "Smalltalk voice" and
help in improving my Smalltalk idioms would be greatly appreciated.
Also, I am looking for a way to write tests for the code. Because
much of the code is based on Seaside/Magritte callbacks, it seems
difficult to test the code without being able to simulate these
calls. Any pointers to testing would be appreciated.
Thanks,
David
In my first scalability run, the tree view widget is struggling to
handle 250 pages. Particularly since it appears to display with all
leaves open by default.
Keith
___________________________________________________________
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
I have uploaded a first release of a scriptingAPI for pier.
The aim at this stage is to provide a platform for importing data and
hence some scalability testing with pier-magma.
There are three classes which implement the same API.
a) PRModelScripter - direct operations on the model
b) PRCommandScripter - operations via the command interface (logging
optional)
c) PRCommandAppScripter - as b) but run in the context of the registered
application including logging (optional) and persistency.
For Data importing PRPierifyToPage provides an abstract class for
loading data from a target object into a pier page.
Example of use:
(PRPierifySmalltalkClass target: Object into: (PRCommandAppScripter
onKernelNamed:'pier')
So to create a persisted Pier kernel with 5000+ pages, one every 10 seconds.
Create a persisted kernel named 'Squeak' using the Magma Control Panel
GUI. Then run.
PRPierifySmalltalkClass pace: 10.
PRPierifySmalltalkClass exampleProtoObject.
[ PRPierifySmalltalkClass exampleAllClasses ] forkAt: 15.
feedback welcome
Keith
___________________________________________________________
All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine
http://uk.docs.yahoo.com/nowyoucan.html
Findings so far.
I have persisted 248 pages so far (a far cry from the promised 5000!)
but I am doing so slowly.
Magma reports 84818 objects from aRepositoryController objectCount.
That is an average of 342 objects per page. Although Pier pages do
contain a lot of objects to describe what most wiki's store in a single
string. 342 seems to be quite a lot.
Disk usage is 3Mb for 250 pages which is 12k per page, i.e. 60Mb for a
site of 5000 pages with one page generated per Squeak class.
So I opened an explorer on the repository and took a look at a simple page.
The page generated for Squeak class 'Password' seemed to be quite
typical, not too large. (I didn't even know squeak had a class called
Password).
The page consists of headings, the class comment, a list of subclasses
(Password has none)
an unordered list of instance methods each being a [broken] link (i.e.
pages for individual methods have not been filled in) and a similar
unordered list of class methods.
Counting objects in the repository explorer I get approximately 102
unique Objects, 50 nil's, and 8 object references. Just for one page!
160 Objects that I can explicitly count, I am not sure what Magma is
doing behind the scenes in terms of overhead.
The only thing that I can see that could be optimised is the appearance
of 9 empty arrays ( #decoration and #children ) which could be lazily
initialialized. I doubt if it is worth doing what is the overhead of
storing an empty array, as opposed to nil?
Keith
___________________________________________________________
Try the all-new Yahoo! Mail. "The New Version is radically easier to use" The Wall Street Journal
http://uk.docs.yahoo.com/nowyoucan.html
