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 _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki PierWysiwyg.png (68K) Download Attachment |
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 <[hidden email]> 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 _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Hi Lukas,
This is really cool and works amazingly well! Thanks.
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 _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
> 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 _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
You need to tell the document its "owning" structure, you shouldn't 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.
_______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Administrator
|
In reply to this post by Nick
This is good stuff Nick!
|
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 <[hidden email]> 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 _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Hi,
Ahh, one question: Why do you go through the wiki syntax at all? 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 _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Now I think I understand:
I guess won't have to worry about escaping the text... _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
also...
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]
_______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
continuing the debate with myself:
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.
_______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
In reply to this post by Nick
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 <[hidden email]> 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 _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Continuing the thinking aloud: The wiki syntax evolved from SWiki, WikiWorks, and SmallWiki and is a Could the wiki syntax be represented in PetitParser form? Would that simplify the parser? _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
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 <[hidden email]> 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 _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Currently the WYSIWYG editor maintains but doesn't allow insertion of:
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.
_______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
In reply to this post by Lukas Renggli
On 19 July 2011 11:25, Lukas Renggli <[hidden email]> wrote:
Yeah, a PetitParser syntax has long been on my todo list and I even 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.
_______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Free forum by Nabble | Edit this page |