Camp Smalltalk Vanisle presentation - Squeak Services
Locked
Camp Smalltalk Vanisle presentation - Squeak Services
 
|
Here are my notes on a presentation I made here in Nanaimo on the homepage, SqueakMap, and Swiki. The two main ideas are adding a wiki interface to the current homepage and converting Swiki XML files to object graphs that can be rendered in Seaside and HelpBrowser. Chris Camp Smalltalk Vanisle presentation - homepage; Squeak Map Server; Swiki: an exploration of where these three applications are and where they could go - the code is available at SqueakSource3 at SqueakServices - this stuff is politically contentious; I’m not speaking for the Squeak community; it’s just an interesting problem space - the focus of this talk is to explore an idea. That idea is to write a TinyWiki graph Generator for Xtreams called TWGraphGenerator - Is it possible that creating this subclass of Actor in XTreams could be useful in both the homepage and in a Squeak wiki application? - show the two Shapes app graphics 1. Homepage: Altitude (XTreams) & Twitter Bootstrap - the video for XTreams is Martin Kobetic at Barcelona ESUG 2010 on YouTube - Altitude: tour the running application; move to the the keys; change the URI strategy; then go to the locator; then talk about resources - self first resources at: (self first resources keys first) - show ALExampleApplication>>initializeLocator; show hierarchy of ALExample classes - show squeak.org; talk about 24 char foo versus squeak.org URIs - no rendering tree; has inheritance for its pages - it’s mainly about Twitter Bootstrap and could be skinned to any framework - some miss Aida; but is that what they really miss? A wiki interface. That’s what the code behind the homepage should do - go back to the Shapes app graphics 2. SMServer: Seaside2.8 & SqueakSource & Twitter Bootstrap - HTTPView2 - SMBaseView to HVHttpView and its hierarchy; pages as subclasses; - SMSqueakMapView>>#default - has a Canvas and a Builder like Seaside2.6; compare the Builder to the Canvas with #anchorWithPopupAction:name:extent:toggles:do:; moved from one method per tag to one class per tag - HTTPView2 never evolved to the Canvas it was developing; show selectors for #newaccount in HTTPView2 - There is no HTTPView2 that I can obtain that works in localhost. - sm directory with map files and accounts and cache dirs; there is /sm/accounts and /sm/cache/; One for the server; one for the client; Why does the server have cache directories at all? I don’t know. - the concept of gathering content in the cloud and consuming it on a desktop with a file is a good one that could be extended to the Swiki - SMServer; talk about the object graph of the model; Account—>Package—>Release - uses a list component from SqueakSource; uses WALabelledFormDialog for forms - you can see it running at oopfile.com - 3. Swiki: Seaside2.8 & SqueakSource & Twitter Bootstrap & TinyWiki - show the XML files - ComSwiki - show the wiki format in the edit button of a running ComSwiki - transform the XML files into an intermediate text format with a NuSwikiPageConverter - the NuSwikiPageConverter is an image with Swiki.cs and SS2 - Then feed those strings in the Swiki format to an XTreams parser using #grammarWiki and TWGraphGenerator to make an object graph like TinyWiki’s - we turn every XML page into an instance of TinyWiki; TinyWiki is the wiki in every SqueakSource project that nobody uses - then we render them in Seaside with an application, which could be Ohana - Ohana is Hawaiian for ‘family’, as in ‘a family of wiki objects’; TinyWiki instances - change the text files into TWFolder instances and then render them in both Seaside and the HelpBrowser - perhaps use a program like Ohana, which is a hacked SqueakSource the brings the TinyWiki instances to the fore - or use Pier, but I suspect an older version in a Seaside 2.8 would be easier to manage than an current version of Pier - all XML pages would be stored as TWFolder objects in a single SSRepository, which could be downloaded and rendered in HelpBrowser by writing a subclass for TWVisitor - covert the TWFolder object graph to the HelpTopic object graph with the Visitor pattern in TinyWiki - the class that makes this all possible is SSProject; it’s stored in SSRepository; it has three ivars that are useful and powerful, which are id; wiki; and viewer - if you want a page with not just one TinyWiki, but several or with components, you subclass SSProjectView - use XTreams to replace SmallCC, TWScanner, and TWParser by creating a TWGraphGenerator class - use the idea of collecting content form a web app and consuming it locally from a file in the manner of SqueakMap and its map file - show the second Shapes app image again |
Re: Camp Smalltalk Vanisle presentation - Squeak Services
|
|
Hey!
On 10/05/2014 03:00 PM, Chris Cunnington wrote: > *2. SMServer: Seaside2.8 & SqueakSource & Twitter Bootstrap * > > - HTTPView2 > - SMBaseView to HVHttpView and its hierarchy; pages as subclasses; > - SMSqueakMapView>>#default > - has a Canvas and a Builder like Seaside2.6; compare the Builder to the > Canvas with #anchorWithPopupAction:name:extent:toggles:do:; moved from > one method per tag to one class per tag > - HTTPView2 never evolved to the Canvas it was developing; show > selectors for #newaccount in HTTPView2 In fact, I started on a new HV2 that reused the canvas from Seaside basically (and I think Giovanni also worked on something similar), it basically worked but I then moved on to Seaside personally. > - There is no HTTPView2 that I can obtain that works in localhost. ? > - sm directory with map files and accounts and cache dirs; there is > /sm/accounts and /sm/cache/; One for the server; one for the client; Why > does the server have cache directories at all? I don’t know. Because the idea was that if the original URL ended up broken, the SM server can still serve the file from its own cache. IIRC this mechanism still works? When you add a release and enter a URL for the file, the server should download it to its own cache. regards, Göran |
Re: Camp Smalltalk Vanisle presentation - Squeak Services
|
|
On Oct 6, 2014, at 2:49 AM, Göran Krampe <[hidden email]> wrote: > Hey! > > On 10/05/2014 03:00 PM, Chris Cunnington wrote: >> *2. SMServer: Seaside2.8 & SqueakSource & Twitter Bootstrap * >> >> - HTTPView2 >> - SMBaseView to HVHttpView and its hierarchy; pages as subclasses; >> - SMSqueakMapView>>#default >> - has a Canvas and a Builder like Seaside2.6; compare the Builder to the >> Canvas with #anchorWithPopupAction:name:extent:toggles:do:; moved from >> one method per tag to one class per tag >> - HTTPView2 never evolved to the Canvas it was developing; show >> selectors for #newaccount in HTTPView2 > > In fact, I started on a new HV2 that reused the canvas from Seaside basically (and I think Giovanni also worked on something similar), it basically worked but I then moved on to Seaside personally. > >> - There is no HTTPView2 that I can obtain that works in localhost. > > ? > >> - sm directory with map files and accounts and cache dirs; there is >> /sm/accounts and /sm/cache/; One for the server; one for the client; Why >> does the server have cache directories at all? I don’t know. > > Because the idea was that if the original URL ended up broken, the SM server can still serve the file from its own cache. IIRC this mechanism still works? > When you add a release and enter a URL for the file, the server should download it to its own cache. This is wholly new to me. And it fills a whole in my understanding of SqueakMap. I’m going to explore this with better understanding. Thanks for explaining that. Chris > > regards, Göran > > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |