14 Jul
2011
14 Jul
'11
12:37 a.m.
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/
14 Jul
14 Jul
10:15 a.m.
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 <nick.ager(a)gmail.com> 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
12:01 p.m.
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
8:27 p.m.
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
19 Jul
19 Jul
9:34 a.m.
This is good stuff Nick!
--
View this message in context:
http://forum.world.st/Initial-release-of-Wysiwyg-editor-for-Pier-tp3666278p…
Sent from the Magritte, Pier and Related Tools mailing list archive at Nabble.com.
9:39 a.m.
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 <geert.wl.claes(a)gmail.com> wrote:
This is good stuff Nick!
--
View this message in context:
http://forum.world.st/Initial-release-of-Wysiwyg-editor-for-Pier-tp3666278p…
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
11:13 a.m.
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
11:46 a.m.
also...
What do you see as the benefits of translating into a
javascript PRDocument
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
type structure?
11:56 a.m.
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.
12:02 p.m.
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 <nick.ager(a)gmail.com> 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
12:16 p.m.
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?
12:25 p.m.
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 <nick.ager(a)gmail.com> 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
12:57 p.m.
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.
1:04 p.m.
On 19 July 2011 11:25, Lukas Renggli <renggli(a)gmail.com> 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.
4666
days inactive
4672
days old
15 comments
3 participants
participants (3)
-
Geert Claes -
Lukas Renggli -
Nick Ager