From nick.ager at gmail.com Tue Jul 5 07:46:34 2011 From: nick.ager at gmail.com (Nick Ager) Date: Tue, 5 Jul 2011 06:46:34 +0100 Subject: Pier sprint Eindhoven Message-ID: Hi, Over the weekend in Eindhoven we focused our efforts on building a friendly admin interface for Pier. The concept was that rather than having the admin features within site's environment (~template), we wrap a pier site in an admin interface which would be available from a different url (eg www.mysite.com/admin or admin.mysite.com). See attached screen grab. This is very much still a WIP. The reasons for this approach were: 1) Focus the site's environment on the contents of the site and not to be worried about the administration interface. 2) Simplify the site's environment by removing the administration tools. 3) Remove the concern that editing the site's environment could break the admin interface. 4) Provide a consistent admin interface across all Pier sites. 5) Ensure that the admin url is secure. That said it's probably not as black-and-white as I've implied; there are some admin or editorial tasks which would probably make sense to keep within the site, for example add a new blog post, edit a page. The WIP admin interface is available in repository: ' http://source.lukas-renggli.ch/pier2addons', package: 'Pier-Admin'. Until we update a Metacello configuration there are some class site installation helpers: PRAdminFrame class >> #loadDependentPackages PRAdminFrame class >> #register Hope this makes sense Nick The attendees where: Adriaan van Os Louis Andriese thomas noordzij Julian Fitzell Maarten Daalder Norbert Hartl Bart Veenstra Nick Ager Reza Razavi Stephan Eggermont Friso Geerlings hope I haven't missed anyone -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen shot 2011-07-05 at 05.24.37.png Type: image/png Size: 123125 bytes Desc: not available URL: From nick.ager at gmail.com Tue Jul 5 10:25:58 2011 From: nick.ager at gmail.com (Nick Ager) Date: Tue, 5 Jul 2011 09:25:58 +0100 Subject: post Pier sprint - packages, repositories, files Message-ID: Hi, All the work in the Eindhoven sprint repository is now checked into the pier2, pier2addons or Seaside30Addons repositories. In the process I performed a little refactoring on some of our work. Admin interface ============ Found in pier2addons, Pier-Admin PRAdminFrame class contains various helpers for loading and configuring; see #loadDependentPackages, #register, #configureFileLibrary I've put Thomas's files into PRAdminFileLibrary, as it seems to be the easiest way to distribute the files. However for Thomas to continue to work on the design it probably makes sense to export the files then use an external file library to serve them. To export the files: PRAdminFileLibrary deployFiles. ...which will result in a folder PRAdminFileLibrary containing the files in the same directory as the running image. As WAFileLibrary currently (I think) doesn't support paths, I've put removed the img folder and moved the images into the same folder as the css file. I've also renamed pier.css to pieradmin.css as it's the css associated with the admin interface. Maarten's #browseCssClass I've refactored so that #cssClass now allows a specific css class to be specified for a structure. I think that makes sense to expand #cssClass rather than having the potential confusion of two methods which providing similar functionality. I've removed PRAdminDistribution as it largely replicated PRDistribution. I took the register changes into PRAdminFrame class >> #register. I guess we either need to modify PRDistribution to come up with a pier show-case distribution or create a new distribution. Ideally the admin interface will allow these distributions to be browsed and installed - it currently allows switching between different pier kernels. Pier-Ace ====== Pier-Ace - copied directly into pier2addons - I'm afraid I missed Bart's demo - perhaps Bart could explain more... Simple external file support. ==================== Adriaan's WAExternalFileLibrary has been renamed WAFileSystemFileLibrary (from WAExternalFileLibrary to avoid a name collision) and I've checked it into the repository: 'http://www.squeaksource.com/Seaside30Addons' package 'Seaside-FileSystemLibrary'. Maybe it should become part of Seaside-Core in the future Security changes ============= I've copied Reza's security changes directly into PRDistribution. I think there are more to come - though this also has to do with our Pier kernel boot-strapping approach from the admin interface. Pier-Wysiwyg ========== The Wysiwyg editor work Norbert and I started on Sunday afternoon is in pier2addons - package Pier-Wysiwyg. Again I've put the external Javascript library into a WAFileLibrary for ease of distribution. The approach looks promising though this is a very early version. still to come ========= Bart's JQuery tree widget which we can then integrate into the admin interface. Hope this makes sense. Shout if I missed something or you violently disagree with the "tidying" I've performed prior to check-in. Thanks all for a great weekend Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From norbert at hartl.name Tue Jul 5 10:56:35 2011 From: norbert at hartl.name (Norbert Hartl) Date: Tue, 5 Jul 2011 10:56:35 +0200 Subject: Pier sprint Eindhoven In-Reply-To: References: Message-ID: <2825546B-980D-4905-A0CF-B0AEEAC3770D@hartl.name> Thanks Nick for wrapping this up. Norbert Am 05.07.2011 um 07:46 schrieb Nick Ager: > Hi, > > Over the weekend in Eindhoven we focused our efforts on building a friendly admin interface for Pier. The concept was that rather than having the admin features within site's environment (~template), we wrap a pier site in an admin interface which would be available from a different url (eg www.mysite.com/admin or admin.mysite.com). See attached screen grab. This is very much still a WIP. The reasons for this approach were: > 1) Focus the site's environment on the contents of the site and not to be worried about the administration interface. > 2) Simplify the site's environment by removing the administration tools. > 3) Remove the concern that editing the site's environment could break the admin interface. > 4) Provide a consistent admin interface across all Pier sites. > 5) Ensure that the admin url is secure. > > That said it's probably not as black-and-white as I've implied; there are some admin or editorial tasks which would probably make sense to keep within the site, for example add a new blog post, edit a page. > > The WIP admin interface is available in repository: 'http://source.lukas-renggli.ch/pier2addons', package: 'Pier-Admin'. Until we update a Metacello configuration there are some class site installation helpers: > PRAdminFrame class >> #loadDependentPackages > PRAdminFrame class >> #register > > Hope this makes sense > > Nick > > The attendees where: > Adriaan van Os > Louis Andriese > thomas noordzij > Julian Fitzell > Maarten Daalder > Norbert Hartl > Bart Veenstra > Nick Ager > Reza Razavi > Stephan Eggermont > Friso Geerlings > > hope I haven't missed anyone > > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki -------------- next part -------------- An HTML attachment was scrubbed... URL: From razavi at acm.org Tue Jul 5 11:06:16 2011 From: razavi at acm.org (Reza Razavi) Date: Tue, 05 Jul 2011 11:06:16 +0200 Subject: Pier sprint Eindhoven In-Reply-To: <2825546B-980D-4905-A0CF-B0AEEAC3770D@hartl.name> References: <2825546B-980D-4905-A0CF-B0AEEAC3770D@hartl.name> Message-ID: At 10:56 05/07/2011, Norbert Hartl wrote: >Thanks Nick for wrapping this up. Indeed impressive; thanks Nick, the organizers, and all other participants! Reza PS: Goya will send you soon your respective photos ;-) From landriese at gmail.com Tue Jul 5 22:22:47 2011 From: landriese at gmail.com (Louis Andriese) Date: Tue, 5 Jul 2011 13:22:47 -0700 (PDT) Subject: post Pier sprint - packages, repositories, files In-Reply-To: References: Message-ID: <1309897367580-3647025.post@n4.nabble.com> Hi Nick, thanks for integrating all this stuff. To all the participants: thank you for taking the time to come to Eindhoven. The thing I liked best is that our combined inspiration has led to a valuable improvement of Pier, that wouldn't have been possible without meeting irl. Now let's keep that fire burning ;) Kind regards, Louis -- View this message in context: http://forum.world.st/post-Pier-sprint-packages-repositories-files-tp3645400p3647025.html Sent from the Magritte, Pier and Related Tools mailing list archive at Nabble.com. From avanos at xs4all.nl Tue Jul 5 23:33:03 2011 From: avanos at xs4all.nl (Adriaan van Os) Date: Tue, 5 Jul 2011 23:33:03 +0200 Subject: Some pictures of the Pier Sprint in Eindhoven... Message-ID: <1994b285fafc34a7deec7e064ba49e5c.squirrel@webmail.xs4all.nl> ... are available at http://www.a3aan.st/ps2011/index.php/list/0/01+Sprint Cheers, Adriaan. -- http://www.a3aan.st From tudor at tudorgirba.com Tue Jul 12 20:55:38 2011 From: tudor at tudorgirba.com (Tudor Girba) Date: Tue, 12 Jul 2011 20:55:38 +0200 Subject: magritte forms for elements in a collection Message-ID: <19234322-329B-4519-8B7B-95B89C1339B4@tudorgirba.com> Hi, I have the following use case that I want to solve using Magritte. I have entities that have Magritte descriptions. If I have one entity, I can nicely edit its description, and when I press Save, it changes the values from the entities. Now, I also have collections of entities that have the same descriptions I would like to use the rendering of Magritte to edit the values for all entities in the collection and when I press Save it should change the values for all entities. Is there any direct support for something like that? Cheers, Doru -- www.tudorgirba.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge." From renggli at gmail.com Wed Jul 13 10:25:46 2011 From: renggli at gmail.com (Lukas Renggli) Date: Wed, 13 Jul 2011 10:25:46 +0200 Subject: [Moose-dev] magritte forms for elements in a collection In-Reply-To: <19234322-329B-4519-8B7B-95B89C1339B4@tudorgirba.com> References: <19234322-329B-4519-8B7B-95B89C1339B4@tudorgirba.com> Message-ID: I discussed this with Doru offline and my suggestion was to edit an MAAdaptiveModel with the common descriptions of all the objects. And afterwards iterate over the objects and the descriptions and apply all values from the MAAdaptiveModel instance to the objects. Lukas On 12 July 2011 20:55, Tudor Girba wrote: > Hi, > > I have the following use case that I want to solve using Magritte. I have entities that have Magritte descriptions. If I have one entity, I can nicely edit its description, and when I press Save, it changes the values from the entities. > > Now, I also have collections of entities that have the same descriptions I would like to use the rendering of Magritte to edit the values for all entities in the collection and when I press Save it should change the values for all entities. Is there any direct support for something like that? > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Yesterday is a fact. > ?Tomorrow is a possibility. > ?Today is a challenge." > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > -- Lukas Renggli www.lukas-renggli.ch From nick.ager at gmail.com Thu Jul 14 00:37:59 2011 From: nick.ager at gmail.com (Nick Ager) Date: Wed, 13 Jul 2011 23:37:59 +0100 Subject: Initial release of Wysiwyg editor for Pier Message-ID: Hi, I've been working on a Wysiwyg editor for Pier, (see attachment). It seems to be in a useable state and I'd love to receive some feedback The editor currently supports all the Pier markup I'm aware of, except tables. That said not all markup is possible to create in wysiwyg mode, however the editor aims to preserve all markup and allow editing of markup created in wiki mode. For example annotated paragraphs can be created in wiki mode, then edited in a Wysiwyg mode. Special Pier markup such as verbatim, embedded links etc are shown and preserved in the Wysiwyg editor, but are not editable. To give it a spin, from a Pier image execute: Gofer it renggli: 'pier2addons'; package: 'Pier-Wysiwyg'; load. Then browse to /wysiwygtest and you should see a test editor, which allows switching between wysiwyg and wiki editors with changes in either editor being reflected in both editors. The html parser walks the browser's DOM, and translates into Pier wiki format. There's a set of tests for the parser, which can be loaded with: Gofer it renggli: 'pier2addons'; package: 'ConfigurationOfPierWysiwygEditor'; load. (ConfigurationOfPierWysiwygEditor project version: #bleedingEdge) load: #('Core' 'Tests'). Then browse to /testwysiwgParser The tests are written in the Jasmine Javascript test framework [1], so run in the browser. I'm still trying to work out the best method to integrate into Pier. If you want to try the editor within Pier modify: PRDocumentDescription class>>defaultComponentClasses ^ Array with: PRWysiwygEditorComponent I've yet to find a method to integrate with Pier without modifying at least one Pier method. Any thoughts? Changing the above method also results in the editor being visible blog comments, which in it's current state probably isn't desirable. Next steps: - add support for preserving table markup - add a preview tab - support enabling/disabling depending upon user permission. Thanks Nick 1 http://pivotal.github.com/jasmine/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PierWysiwyg.png Type: image/png Size: 51592 bytes Desc: not available URL: From renggli at gmail.com Thu Jul 14 10:15:58 2011 From: renggli at gmail.com (Lukas Renggli) Date: Thu, 14 Jul 2011 10:15:58 +0200 Subject: Initial release of Wysiwyg editor for Pier In-Reply-To: References: Message-ID: This is really cool and works amazingly well! For the integration you could add a Magritte extension method to PRCase to change the Magritte component used to edit documents: descriptionDocumentWysiwig: aDescription ^ aDescription componentClass: MyWysiwigComponent Lukas On 14 July 2011 00:37, Nick Ager wrote: > Hi, > I've been working on a Wysiwyg editor for Pier, (see attachment). It seems > to be in a useable state and I'd love to receive some feedback The editor > currently supports all the Pier markup I'm aware of, except tables. That > said not all markup is possible to create in wysiwyg mode, however the > editor aims to preserve all markup and allow editing of markup created in > wiki mode. For example annotated paragraphs can be created in wiki mode, > then edited in a Wysiwyg mode. Special Pier markup such as verbatim, > embedded links etc are shown and preserved in the?Wysiwyg ?editor, but are > not editable. > To give it a spin, from a Pier image execute: > Gofer it > renggli: 'pier2addons'; > ?? package: 'Pier-Wysiwyg'; > ? load. > Then browse to /wysiwygtest and you should see a test editor, which allows > switching between wysiwyg and wiki editors with changes in either editor > being reflected in both editors. > The html parser walks the browser's DOM, and translates into Pier wiki > format. There's a set of tests for the parser, which can be loaded with: > Gofer it > renggli: 'pier2addons'; > ?? package: 'ConfigurationOfPierWysiwygEditor'; > ? load. > (ConfigurationOfPierWysiwygEditor project version: #bleedingEdge) load: > #('Core' 'Tests'). > Then browse to /testwysiwgParser ?The tests are written in the Jasmine > Javascript test framework [1], so run in the browser. > I'm still trying to work out the best method to integrate into Pier. If you > want to try the editor within Pier modify: > PRDocumentDescription class>>defaultComponentClasses > ^ Array with: PRWysiwygEditorComponent > I've yet to find a method to integrate with Pier without modifying at least > one Pier method. Any thoughts? Changing the above method also results in the > editor being visible blog comments, which in it's current state probably > isn't desirable. > Next steps: > - add support for preserving table markup > - add a preview tab > - support enabling/disabling depending upon user permission. > Thanks > Nick > 1?http://pivotal.github.com/jasmine/ > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- Lukas Renggli www.lukas-renggli.ch From nick.ager at gmail.com Thu Jul 14 12:01:04 2011 From: nick.ager at gmail.com (Nick Ager) Date: Thu, 14 Jul 2011 11:01:04 +0100 Subject: Initial release of Wysiwyg editor for Pier In-Reply-To: References: Message-ID: Hi Lukas, This is really cool and works amazingly well! > Thanks. > > For the integration you could add a Magritte extension method to > PRCase to change the Magritte component used to edit documents: > > descriptionDocumentWysiwig: aDescription > ^ aDescription componentClass: MyWysiwigComponent > Done - now when you install the 'Pier-Wysiwyg' package the default editor changes to be the Wysiwyg editor - I knew there would be an easy solution. There's a problem rendering internal links, which I guess is because I'm parsing the wiki text removed from the site's structure. I'm not sure the best way to fix this. Do I attach the editing structure temporarily to the main site? Then remove it when I've finished editing? Here is my method for rendering a preview of the text being edited: renderPreviewOn: html | parsedStructure renderer | html div id: self previewId; with: [ parsedStructure := PRDocumentParser parseStream: self wikiText readStream. renderer := PRViewRenderer new. renderer withinContentDo: [ renderer start: parsedStructure in: self on: html ] ] Any thoughts? Thanks Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From renggli at gmail.com Thu Jul 14 20:27:23 2011 From: renggli at gmail.com (Lukas Renggli) Date: Thu, 14 Jul 2011 20:27:23 +0200 Subject: Initial release of Wysiwyg editor for Pier In-Reply-To: References: Message-ID: > There's a problem rendering internal links, which I guess is because I'm > parsing the wiki text removed from the site's structure. I'm not sure the > best way to fix this. Do I attach the editing structure temporarily to the > main site? Then remove it when I've finished editing? You need to tell the document its "owning" structure, you shouldn't need to actually attach it to a structure: aDocument owner: aStructure Cheers, Lukas -- Lukas Renggli www.lukas-renggli.ch From nick.ager at gmail.com Fri Jul 15 18:54:05 2011 From: nick.ager at gmail.com (Nick Ager) Date: Fri, 15 Jul 2011 17:54:05 +0100 Subject: Initial release of Wysiwyg editor for Pier In-Reply-To: References: Message-ID: > > You need to tell the document its "owning" structure, you shouldn't > need to actually attach it to a structure: > > aDocument owner: aStructure > Thanks Lukas, that was a simple fix. I've found a few problems in the link parsing, which I've fixed - so it seems good to go. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.ager at gmail.com Mon Jul 18 16:36:15 2011 From: nick.ager at gmail.com (Nick Ager) Date: Mon, 18 Jul 2011 15:36:15 +0100 Subject: Wysiwyg parser escaping markup Message-ID: Hi, I added code to the Wysiwyg editor to escape markup within text nodes. To illustrate here is an example from the (javascript) test-suite: it("should escaped text containing link markup", function() { expect("To create a link, put it between *").shouldParseInto("To create a link, put it between ==\\*=="); }); This works fine, the problem arises with: it("should escaped text containing code markup", function() { expect("To make something monospaced, surround it with ==").shouldParseInto("To make something ==monospaced==, surround it with ==\\=\\==="); }); Should text containing '==' translate into '\==' OR '\=\='. rendering ' ==\==== ' into html [1] results in: '

==

' whereas rendering '==\=\=== ' into html results in: '

==

' The html reflects the PRDocument structure. It seems that PRDocumentParser doesn't parse ' ==\==== ' as expected. Worse the sequence: wiki text-> PRDocument -> wiki text fails: PRWikiWriter write: (PRDocumentParser parse: ' ==\=\=== ') => ' ==\==== ' However I have a fix. I've locally modified PRDocumentParser class>>#escape:using: so that any multi-character markup is multiply escaped: '@@' -> '\@\@' '--' => '\-\-' This seems to solve the ambiguous parsing problem and the round-trip problem. Great. However many tests will need rewriting to reflect that any multi-character markup is escaped with multiple slashes. Before fixing the tests, I wanted to check that people thought it made sense. Thanks Nick [1] | document renderer | document := PRDocumentParser parse: ' ==\==== '. renderer := PRViewRenderer new. ^ WAHtmlCanvas builder fullDocument: false; render: [ :r | renderer withinContentDo: [ renderer start: document in: self on: r ] ]. -------------- next part -------------- An HTML attachment was scrubbed... URL: From renggli at gmail.com Mon Jul 18 21:53:49 2011 From: renggli at gmail.com (Lukas Renggli) Date: Mon, 18 Jul 2011 21:53:49 +0200 Subject: Wysiwyg parser escaping markup In-Reply-To: References: Message-ID: Hi Nick, I don't have a computer in the coming week to teat out, so bear with me if I missinderstand something. The reason == is escaped as \== is that only in this case this is problematic, if all markup characters were escaped we would beed to escape also a single occurrnce of = to \=. No? Lukas On Monday, 18 July 2011, Nick Ager wrote: > Hi, > I added code to the Wysiwyg editor to escape markup within text nodes. To illustrate here is an example from the (javascript) test-suite: > it("should escaped text containing link markup", function() { > expect("To create a link, put it between *").shouldParseInto("To create a link, put it between ==\\*=="); > }); > > This works fine, the problem arises with: > it("should escaped text containing code markup", function() { > expect("To make something monospaced, surround it with ==").shouldParseInto("To make something ==monospaced==, surround it with ==\\=\\==="); > }); > Should text containing '==' translate into '\==' OR '\=\='. > rendering?' ==\==== '?into html [1] results in: > ?? ?'

==

' > whereas rendering??'==\=\=== ' into html results in:?????'

==

' > > The html reflects the PRDocument structure. It seems that?PRDocumentParser doesn't parse?' ==\==== ' as expected.Worse the sequence: wiki text-> PRDocument -> wiki text fails: > ?? ??PRWikiWriter write: (PRDocumentParser parse: ?' ==\=\=== ') ?=>?' ==\==== ' > However I have a fix. I've locally modified PRDocumentParser class>>#escape:using: so that any multi-character markup is multiply escaped: > ?'@@' -> '\@\@'?'--' => '\-\-' > This seems to solve the ambiguous parsing problem and the round-trip problem. Great. However many tests will need rewriting to reflect that any multi-character markup is escaped with multiple slashes. Before fixing the tests, I wanted to check that people thought it made sense. > > Thanks > Nick > [1] | ?document renderer | > document := PRDocumentParser parse: ' ==\==== '. renderer := PRViewRenderer new. > ^ WAHtmlCanvas builder fullDocument: false; > render: [ :r | renderer withinContentDo: [ renderer start: ?document in: self on: r ] ]. > -- Lukas Renggli www.lukas-renggli.ch From nick.ager at gmail.com Mon Jul 18 22:46:23 2011 From: nick.ager at gmail.com (Nick Ager) Date: Mon, 18 Jul 2011 21:46:23 +0100 Subject: Wysiwyg parser escaping markup In-Reply-To: References: Message-ID: Hi Lukas, Thanks for getting back to me, The reason == is escaped as \== is that only in this case this is > problematic, if all markup characters were escaped we would beed to > escape also a single occurrnce of = to \=. No? > I don't see any problem parsing \=\= or any multi-character markup (eg \@\@) to plain text - I don't think it matters if \= and \=\= is ambiguous as all you're only interested in producing the '=' character, free from interpretation as any markup. How about I fix the failing tests and in the process make sure it all works as intended and if so check in the changes. We can always roll-back if I've missed something. Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.ager at gmail.com Mon Jul 18 23:50:39 2011 From: nick.ager at gmail.com (Nick Ager) Date: Mon, 18 Jul 2011 22:50:39 +0100 Subject: Wysiwyg parser escaping markup In-Reply-To: References: Message-ID: I've checked in the changes. There were only a couple of tests that needed modifying, they acted as base tests for derived classes and made the number of test failures seem large. If I've missed something I'm happy to roll-back: Name: Pier-Model-NickAger.411 Author: NickAger Time: 18 July 2011, 10:47:33 pm UUID: d23e8ad0-6e18-4f69-a7fc-7399a8493379 Ancestors: Pier-Model-NickAger.410 modified the way markup is escaped, so that: '@@' is now escaped as: '\@\@' rather than as previously: '\@@' Name: Pier-Tests-Model-NickAger.23 Author: NickAger Time: 18 July 2011, 10:44:42 pm UUID: d6cb4015-84c6-45c1-8daa-6f3357f63d92 Ancestors: Pier-Tests-Model-NickAger.22, Pier-Tests-Model-lr.21 modified tests to reflect changes in escaped markup: '@@' => '\@\@' -------------- next part -------------- An HTML attachment was scrubbed... URL: From geert.wl.claes at gmail.com Tue Jul 19 09:34:14 2011 From: geert.wl.claes at gmail.com (Geert Claes) Date: Tue, 19 Jul 2011 00:34:14 -0700 (PDT) Subject: Initial release of Wysiwyg editor for Pier In-Reply-To: References: Message-ID: <1311060854150-3677483.post@n4.nabble.com> This is good stuff Nick! -- View this message in context: http://forum.world.st/Initial-release-of-Wysiwyg-editor-for-Pier-tp3666278p3677483.html Sent from the Magritte, Pier and Related Tools mailing list archive at Nabble.com. From renggli at gmail.com Tue Jul 19 09:36:54 2011 From: renggli at gmail.com (Lukas Renggli) Date: Tue, 19 Jul 2011 09:36:54 +0200 Subject: Wysiwyg parser escaping markup In-Reply-To: References: Message-ID: Thank, I will look at it when I am back home. My only worry was that if you had a single = or @ in the text, it would be escaped. Lukas On Tuesday, 19 July 2011, Nick Ager wrote: > I've checked in the changes. There were only a couple of tests that needed modifying, they acted as base tests for derived classes and made the number of test failures seem large. If I've missed something I'm happy to roll-back: > > Name: Pier-Model-NickAger.411Author: NickAgerTime: 18 July 2011, 10:47:33 pmUUID: d23e8ad0-6e18-4f69-a7fc-7399a8493379Ancestors: Pier-Model-NickAger.410 > > modified the way markup is escaped, so that: > '@@' is now escaped as: '\@\@' rather than as previously: '\@@' > Name: Pier-Tests-Model-NickAger.23 > Author: NickAgerTime: 18 July 2011, 10:44:42 pmUUID: d6cb4015-84c6-45c1-8daa-6f3357f63d92Ancestors: Pier-Tests-Model-NickAger.22, Pier-Tests-Model-lr.21 > modified tests to reflect changes in escaped markup: > > '@@' ?=> '\@\@' > > -- Lukas Renggli www.lukas-renggli.ch From renggli at gmail.com Tue Jul 19 09:39:30 2011 From: renggli at gmail.com (Lukas Renggli) Date: Tue, 19 Jul 2011 09:39:30 +0200 Subject: Initial release of Wysiwyg editor for Pier In-Reply-To: <1311060854150-3677483.post@n4.nabble.com> References: <1311060854150-3677483.post@n4.nabble.com> Message-ID: Ahh, one question: Why do you go through the wiki syntax at all? Couldn't you submit the document model as something machine-readable like JSON or XML? On Tuesday, 19 July 2011, Geert Claes wrote: > This is good stuff Nick! > > -- > View this message in context: http://forum.world.st/Initial-release-of-Wysiwyg-editor-for-Pier-tp3666278p3677483.html > Sent from the Magritte, Pier and Related Tools mailing list archive at Nabble.com. > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- Lukas Renggli www.lukas-renggli.ch From nick.ager at gmail.com Tue Jul 19 11:13:01 2011 From: nick.ager at gmail.com (Nick Ager) Date: Tue, 19 Jul 2011 10:13:01 +0100 Subject: Initial release of Wysiwyg editor for Pier In-Reply-To: References: <1311060854150-3677483.post@n4.nabble.com> Message-ID: Hi, Ahh, one question: Why do you go through the wiki syntax at all? > Couldn't you submit the document model as something machine-readable > like JSON or XML? hmm, I guess when I started I assumed it would be easier converting into Pier wiki format and it allowed me to rapidly verify the parser. Also I'd have to translate from JSON into PRDocument on the server whereas the wiki -> PRDocument translator is already written. What do you see as the benefits of translating into a javascript PRDocument type structure? The one benefit I guess is there are less steps html -> PRDocument vs html -> wiki syntax -> PRDocument. Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.ager at gmail.com Tue Jul 19 11:28:07 2011 From: nick.ager at gmail.com (Nick Ager) Date: Tue, 19 Jul 2011 10:28:07 +0100 Subject: Wysiwyg parser escaping markup In-Reply-To: References: Message-ID: Hi, Thank, I will look at it when I am back home. My only worry was that > if you had a single = or @ in the text, it would be escaped. > No that shouldn't happen as the only text to be escaped are: PRDocumentParser buildTextMatcher keys => #('__' '''''' '==' '*' '{{{' '--' > '^^' '@@' '+' '""') PRWikiWriter write: (PRDocumentParser parse: ' my address is > nick.ager at gmail.com ') => ' my address is nick.ager at gmail.com ' All it means is that if you want to escape '@@' you can escape it as '\@\@\ or '\@@', but it escaper will now escape it as '\@\@' so: PRWikiWriter write: (PRDocumentParser parse: ' annotations start with: \@@ > ') => ' annotations start with: \@\@ ' and: PRWikiWriter write: (PRDocumentParser parse: ' annotations start with: \@\@ > ') => ' annotations start with: \@\@ ' Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.ager at gmail.com Tue Jul 19 11:32:11 2011 From: nick.ager at gmail.com (Nick Ager) Date: Tue, 19 Jul 2011 10:32:11 +0100 Subject: Initial release of Wysiwyg editor for Pier In-Reply-To: References: <1311060854150-3677483.post@n4.nabble.com> Message-ID: Now I think I understand: What do you see as the benefits of translating into a javascript PRDocument > type structure? > I guess won't have to worry about escaping the text... -------------- next part -------------- An HTML attachment was scrubbed... URL: From renggli at gmail.com Tue Jul 19 11:42:26 2011 From: renggli at gmail.com (Lukas Renggli) Date: Tue, 19 Jul 2011 11:42:26 +0200 Subject: Wysiwyg parser escaping markup In-Reply-To: References: Message-ID: Ok, sounds cool. On Tuesday, 19 July 2011, Nick Ager wrote: > Hi, > > Thank, I will look at it when I am back home. My only worry was that > if you had a single = or @ in the text, it would be escaped. > > No that shouldn't happen as the only text to be escaped are: > > PRDocumentParser buildTextMatcher keys =>??#('__' '''''' '==' '*' '{{{' '--' '^^' '@@' '+' '""') > > > PRWikiWriter write: (PRDocumentParser parse: ?' my address is nick.ager at gmail.com ') =>?' my address is nick.ager at gmail.com ' > > All it means is that if you want to escape '@@' you can escape it as '\@\@\ or '\@@', but it escaper will now escape it as '\@\@' so: > > PRWikiWriter write: (PRDocumentParser parse: ?' annotations start with: \@@ ') =>??' annotations start with: \@\@ ' > and: > > PRWikiWriter write: (PRDocumentParser parse: ?' annotations start with: \@\@ ') =>??' annotations start with: \@\@ ' > Nick > -- Lukas Renggli www.lukas-renggli.ch From nick.ager at gmail.com Tue Jul 19 11:46:44 2011 From: nick.ager at gmail.com (Nick Ager) Date: Tue, 19 Jul 2011 10:46:44 +0100 Subject: Initial release of Wysiwyg editor for Pier In-Reply-To: References: <1311060854150-3677483.post@n4.nabble.com> Message-ID: also... > What do you see as the benefits of translating into a javascript PRDocument >> type structure? >> > I guess it would make more sense to use a neutral format ie javascript version of PRDocument if Pier would ever support other wiki formats such as Markdown [1] or Google wiki syntax [2] [1] http://en.wikipedia.org/wiki/Markdown [2] http://code.google.com/p/support/wiki/WikiSyntax -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.ager at gmail.com Tue Jul 19 11:56:54 2011 From: nick.ager at gmail.com (Nick Ager) Date: Tue, 19 Jul 2011 10:56:54 +0100 Subject: Initial release of Wysiwyg editor for Pier In-Reply-To: References: <1311060854150-3677483.post@n4.nabble.com> Message-ID: continuing the debate with myself: What do you see as the benefits of translating into a javascript PRDocument >>> type structure? >>> >> negatively, it would mean I'd have to more throughly understand the PRDocument structure and I wonder if it could be more fragile to code changes; whereas the wiki syntax is in use and so has to be maintained in a compatible form. -------------- next part -------------- An HTML attachment was scrubbed... URL: From renggli at gmail.com Tue Jul 19 12:02:01 2011 From: renggli at gmail.com (Lukas Renggli) Date: Tue, 19 Jul 2011 12:02:01 +0200 Subject: Initial release of Wysiwyg editor for Pier In-Reply-To: References: <1311060854150-3677483.post@n4.nabble.com> Message-ID: Well, I am just thinking aloud: The wiki syntax evolved from SWiki, WikiWorks, and SmallWiki and is a major pain to parse and generate. You also see that in the tests, some are marked as expected failures (i.e. link parameters in tables). The syntax is basically designed to be convenient for humans to write, so I thought a tool might prefer some other structure? But if it works well for you, this is cool too :-) On Tuesday, 19 July 2011, Nick Ager wrote: > Hi, > > Ahh, one question: Why do you go through the wiki syntax at all? > Couldn't you submit the document model as something machine-readable > like JSON or XML? > hmm, I guess when I started I assumed it would be easier converting into Pier wiki format and it allowed me to rapidly verify the parser. Also I'd have to translate from JSON into PRDocument on the server whereas the wiki -> PRDocument translator is already written. What do you see as the benefits of translating into a javascript PRDocument type structure? The one benefit I guess is there are less steps html -> PRDocument vs html -> wiki syntax -> PRDocument. > > Nick > > -- Lukas Renggli www.lukas-renggli.ch From nick.ager at gmail.com Tue Jul 19 12:16:06 2011 From: nick.ager at gmail.com (Nick Ager) Date: Tue, 19 Jul 2011 11:16:06 +0100 Subject: Initial release of Wysiwyg editor for Pier In-Reply-To: References: <1311060854150-3677483.post@n4.nabble.com> Message-ID: Continuing the thinking aloud: > The wiki syntax evolved from SWiki, WikiWorks, and SmallWiki and is a > major pain to parse and generate. You also see that in the tests, some > are marked as expected failures (i.e. link parameters in tables). > Could the wiki syntax be represented in PetitParser form? Would that simplify the parser? -------------- next part -------------- An HTML attachment was scrubbed... URL: From renggli at gmail.com Tue Jul 19 12:25:10 2011 From: renggli at gmail.com (Lukas Renggli) Date: Tue, 19 Jul 2011 12:25:10 +0200 Subject: Initial release of Wysiwyg editor for Pier In-Reply-To: References: <1311060854150-3677483.post@n4.nabble.com> Message-ID: Yeah, a PetitParser syntax has long been on my todo list and I even started to write some code (not sure where I have it). It is not easy though, because the grammar is highly context sensitive and extensible (what would be easy with PP). Also if an effort like this is done, we should think about adopting a more common/modern syntax like Creole or YAML or ... And then, I wonder if a wiki syntax still makes sense in the long run if we have a WYSIWYG editor? Lukas On Tuesday, 19 July 2011, Nick Ager wrote: > Continuing the thinking aloud: > The wiki syntax evolved from SWiki, WikiWorks, and SmallWiki and is a > major pain to parse and generate. You also see that in the tests, some > are marked as expected failures (i.e. link parameters in tables). > > Could the wiki syntax be represented in PetitParser form? Would that simplify the parser? > -- Lukas Renggli www.lukas-renggli.ch From nick.ager at gmail.com Tue Jul 19 12:57:00 2011 From: nick.ager at gmail.com (Nick Ager) Date: Tue, 19 Jul 2011 11:57:00 +0100 Subject: Initial release of Wysiwyg editor for Pier In-Reply-To: References: <1311060854150-3677483.post@n4.nabble.com> Message-ID: > > > And then, I wonder if a wiki syntax still makes sense in the long run > if we have a WYSIWYG editor? Currently the WYSIWYG editor maintains but doesn't allow insertion of: - definition list and definitions - preformatted. - shout code formatting. - named anchors - mail to: links - annotated paragraphs - value links - annotations - verbatim - tables - embedded links The editor could be extended to support the above - (I've experimented with providing a site map drop-down for internal links within the anchor dialog in the editor), but it would take some effort and would tie us more to a particular editor. At the moment I'm using YUIs editor - but most of the effort has been in the generic HTML parser rather than to a particular editor. To provide the above within the editor I think it would make sense to review the YUI editor decision, before committing to significant work - perhaps there are better options - even YUI has a new editor (v3) in beta - but it is very incomplete when I looked (no toolbar). Also it would be good to receive feedback from real-world use first. Can book content be edited with the Wysiwyg editor? Do people prefer using the Wysiwyg editor vs the wiki markup. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.ager at gmail.com Tue Jul 19 13:04:49 2011 From: nick.ager at gmail.com (Nick Ager) Date: Tue, 19 Jul 2011 12:04:49 +0100 Subject: Initial release of Wysiwyg editor for Pier In-Reply-To: References: <1311060854150-3677483.post@n4.nabble.com> Message-ID: On 19 July 2011 11:25, Lukas Renggli wrote: > Yeah, a PetitParser syntax has long been on my todo list and I even > started to write some code (not sure where I have it). It is not easy > though, because the grammar is highly context sensitive and extensible > (what would be easy with PP). Also if an effort like this is done, we > should think about adopting a more common/modern syntax like Creole or > YAML or ... > I agree it would make more sense spending effort creating a PetitParser grammar for Creole, Markdown or some-other well used markup then recreating the current parser in PetitParser. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.ager at gmail.com Fri Jul 22 08:55:54 2011 From: nick.ager at gmail.com (Nick Ager) Date: Fri, 22 Jul 2011 07:55:54 +0100 Subject: Pier permissions Message-ID: Hi, I can understand how the current implementation of Pier security could work well in the case of a set of users each with their own sub-tree - a little like Unix's '/home/user1' '/home/user2' etc, where users can control the commands allowed to be executed on their sub-trees. However I'm looking for a more capability model, for example: * does the user have permission to see this view in wiki mode? * does the user have permission to create verbatim html? * does the user have permission to create value links? * etc Is there a sensible way to map this onto the current security implementation? I've currently mapped it with code like: > editorConfiguration allowWikiTextEditing: ((self context command: > PRWikiTextEditingCommand new) isValid). This works however the owner/group/other structure permissions mapping seems too coarse grained. I'd like to be able to have groups relating to these permissions then add groups to users, depending upon the permissions I'd like to assign to them. Am I looking at this in the wrong way? Is there a mechanism to support a capability model? Cheers Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From renggli at gmail.com Fri Jul 22 09:22:29 2011 From: renggli at gmail.com (Lukas Renggli) Date: Fri, 22 Jul 2011 09:22:29 +0200 Subject: Pier permissions In-Reply-To: References: Message-ID: Philippe implemented a capabilities (ACL) based security model. It worked very well, but IMHO was too complicated to setup properly and use (due to the complete freedom). Security is currently based on commands, something like create value links or edit verbatim text does not really fit into that model. What you could easily do however is to create a restricted edit command that doesn't allow to edit these elements. This would follow the pattern of 'edit page' and 'settings page' (earlier on everything was in 'edit page'). Lukas On Friday, 22 July 2011, Nick Ager wrote: > Hi, > I can understand how the current implementation of Pier security could work well in the case of a set of users each with their own sub-tree - a little like Unix's '/home/user1' '/home/user2' etc, where users can control the commands allowed to be executed on their sub-trees. > However I'm looking for a more capability model, for example:* does the user have permission to see this view in wiki mode??* does the user have permission to create verbatim html? > * does the user have permission to create value links?* etc > Is there a sensible way to map this onto the current security implementation? I've currently mapped it with code like: > > editorConfiguration allowWikiTextEditing: ((self context command: PRWikiTextEditingCommand new) ?isValid). > This works however the owner/group/other structure permissions mapping seems too coarse grained. I'd like to be able to have groups relating to these permissions then add groups to users, depending upon the permissions I'd like to assign to them. Am I looking at this in the wrong way? Is there a mechanism to support a capability model? > > Cheers > Nick > -- Lukas Renggli www.lukas-renggli.ch From nick.ager at gmail.com Fri Jul 22 12:35:00 2011 From: nick.ager at gmail.com (Nick Ager) Date: Fri, 22 Jul 2011 11:35:00 +0100 Subject: Pier permissions In-Reply-To: References: Message-ID: Hi, Philippe implemented a capabilities (ACL) based security model. Can you point me at the implementation? Thanks Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From renggli at gmail.com Fri Jul 22 13:13:01 2011 From: renggli at gmail.com (Lukas Renggli) Date: Fri, 22 Jul 2011 13:13:01 +0200 Subject: Pier permissions In-Reply-To: References: Message-ID: Search on SqueakSource for "Pier ACL" and look for mails in the mailing list archive (likely dating back to 2006 or more). Lukas On Friday, 22 July 2011, Nick Ager wrote: > Hi, > > Philippe implemented a capabilities (ACL) based security model. > Can you point me at the implementation? > Thanks > Nick > -- Lukas Renggli www.lukas-renggli.ch From nick.ager at gmail.com Fri Jul 22 13:24:04 2011 From: nick.ager at gmail.com (Nick Ager) Date: Fri, 22 Jul 2011 12:24:04 +0100 Subject: Pier permissions In-Reply-To: References: Message-ID: OK I found: http://www.squeaksource.com/adl which redirected me to: http://source.lukas-renggli.ch/spielverderber which Google translate tell me is "spoilsport" ... hmmm anyway it looks promising On 22 July 2011 12:13, Lukas Renggli wrote: > Search on SqueakSource for "Pier ACL" and look for mails in the > mailing list archive (likely dating back to 2006 or more). > > Lukas > > On Friday, 22 July 2011, Nick Ager wrote: > > Hi, > > > > Philippe implemented a capabilities (ACL) based security model. > > Can you point me at the implementation? > > Thanks > > Nick > > > > -- > Lukas Renggli > www.lukas-renggli.ch > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -------------- next part -------------- An HTML attachment was scrubbed... URL: From renggli at gmail.com Fri Jul 22 15:32:14 2011 From: renggli at gmail.com (Lukas Renggli) Date: Fri, 22 Jul 2011 15:32:14 +0200 Subject: Fwd: [Seaside] SeasideHostings with custom domain names need to update their DNS config In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: Adrian Lienhard Date: Friday, 22 July 2011 Subject: [Seaside] SeasideHostings with custom domain names need to update their DNS config To: Seaside - general discussion This is relevant for SeasideHosting users with their own domain name (if you access the site other than yourname.seasidehosting.st). The SeasideHosting server is getting a new IP address. Some users have their DNS configured to point to the old address (212.103.66.207) and hence need to update. Until 1st of August 2011, please update your DNS configuration as follows. Replace the existing A record (which currently points to 212.103.66.207) with a CNAME record: ? ?CNAME seasidehosting.st If you have any questions, please get in contact directly via seasidehosting at netstyle.ch. Cheers, Adrian_______________________________________________ seaside mailing list seaside at lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside -- Lukas Renggli www.lukas-renggli.ch From davorin.rusevljan at gmail.com Mon Jul 25 10:30:05 2011 From: davorin.rusevljan at gmail.com (Davorin Rusevljan) Date: Mon, 25 Jul 2011 10:30:05 +0200 Subject: PierBook with non-latin characters? Message-ID: Hi I would like to use PierBook to write paper in Croatian, and produce nice latex output with some non latin characters in it. Can I just use Pier2 one click from Lukas jenkins, or some tweaking is required to get a smooth run? Thanks! Davorin Rusevljan http://www.cloud208.com/ From renggli at gmail.com Mon Jul 25 18:19:22 2011 From: renggli at gmail.com (Lukas Renggli) Date: Mon, 25 Jul 2011 18:19:22 +0200 Subject: PierBook with non-latin characters? In-Reply-To: References: Message-ID: On 25 July 2011 10:30, Davorin Rusevljan wrote: > Hi I would like to use PierBook to write paper in Croatian, and > produce nice latex output with some non latin characters in it. > > Can I just use Pier2 one click from Lukas jenkins, or some tweaking is > required to get a smooth run? You have to try. Make sure to select a proper encoding on the server side. Also use a modern LaTeX distribution/template that doesn't require characters to be escaped, but can handle UTF-8. Lukas -- Lukas Renggli www.lukas-renggli.ch From norbert at hartl.name Wed Jul 27 18:54:50 2011 From: norbert at hartl.name (Norbert Hartl) Date: Wed, 27 Jul 2011 18:54:50 +0200 Subject: Approaches for i18n in pier Message-ID: <35854699-2980-4A3A-851A-D665DA8C4C52@hartl.name> Does anybody of you use pier with a multilingual setting? If so I would be interested what approaches you take. I started simple and provided a kernel for each language where the language independent stuff is shared. But the more components I embed the more the whole thing becomes a drag. So I am very interested in any approach you tried (even if you failed) thanks, Norbert From nick.ager at gmail.com Thu Jul 28 18:28:13 2011 From: nick.ager at gmail.com (Nick Ager) Date: Thu, 28 Jul 2011 17:28:13 +0100 Subject: Approaches for i18n in pier In-Reply-To: <35854699-2980-4A3A-851A-D665DA8C4C52@hartl.name> References: <35854699-2980-4A3A-851A-D665DA8C4C52@hartl.name> Message-ID: Hi Norbert, I haven't attempted any i18n in Pier, though I wonder if it would make sense to modify PRCase to store a Dictionary of PRDocuments keyed by language rather than the single document used in the current implementation. Nick On 27 July 2011 17:54, Norbert Hartl wrote: > Does anybody of you use pier with a multilingual setting? If so I would be > interested what approaches you take. > > I started simple and provided a kernel for each language where the language > independent stuff is shared. But the more components I embed the more the > whole thing becomes a drag. > > So I am very interested in any approach you tried (even if you failed) > > thanks, > > Norbert > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -------------- next part -------------- An HTML attachment was scrubbed... URL: From norbert at hartl.name Thu Jul 28 19:13:47 2011 From: norbert at hartl.name (Norbert Hartl) Date: Thu, 28 Jul 2011 19:13:47 +0200 Subject: Approaches for i18n in pier In-Reply-To: References: <35854699-2980-4A3A-851A-D665DA8C4C52@hartl.name> Message-ID: <9A2FB3C5-077F-4F32-94C9-5DC6E04C8006@hartl.name> Nick, yes, I think it should be something like that. I didn't look deeper into it. But there is a already stuff to have multiple documents. If there is a default for locale than it would be the same as it is now. The additional locales would be an extension to the existing structure. This way you could also just use it if you don't care about i18n. Having multiple pages is not the only thing you probably need. I think having the gettext approach would also be really helpful. Especially if your doing components you could have another source of i18n capability. The synthesis of both could be some kind of markup for enabling the gettext style inside a page. Norbert Am 28.07.2011 um 18:28 schrieb Nick Ager: > Hi Norbert, > > I haven't attempted any i18n in Pier, though I wonder if it would make sense to modify PRCase to store a Dictionary of PRDocuments keyed by language rather than the single document used in the current implementation. > > Nick > > On 27 July 2011 17:54, Norbert Hartl wrote: > Does anybody of you use pier with a multilingual setting? If so I would be interested what approaches you take. > > I started simple and provided a kernel for each language where the language independent stuff is shared. But the more components I embed the more the whole thing becomes a drag. > > So I am very interested in any approach you tried (even if you failed) > > thanks, > > Norbert > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki -------------- next part -------------- An HTML attachment was scrubbed... URL: