Ethan Jucovy
2010-09-04 21:46:55 UTC
I've been looking into upgrading Xinha in OpenCore. We currently ship with
a very old version, I think our vendorbranch is cut from Xinha's 0.92b. The
latest release is 0.96(.2) -- and Xinha has supported Safari and Opera since
0.95.
CoActivate.org is now running the 0.96.2 codebase optionally, for people who
want to beta-test it. (If you're a user on CoActivate.org and want to help
test, ping me and I'll set up your account for it.)
I've been extracting the scattered changes we've made on our old
vendorbranch, and am submitting them upstream[1]. I've cut a new
vendorbranch from Xinha's latest ***@r1270 and have applied my upstream
patches there[2]. A few things remain to be extracted - most importantly,
the logic that prevents creation of hyperlinks within ((wicked link text)).
So, we'll definitely be able to ship with at least some flavor of Xinha
0.96+ by the time of opencore's 0.19 release. After the upgrade has settled
I'm also hoping to start adding some more plugins to the configuration, and
perhaps develop some new plugins too, including some opencore-specific ones
like "link to a project" or "click to contact a user."
== Internal details ==
I refactored and rearchitected some things in order to support
CoActivate.org's per-user opt-in upgrade. The biggest hitch was that,
previously, opencore wiki pages and wordpress blog posts were each serving
their own copies of the Xinha configuration. They were rendering the same
JavaScript code, but it wasn't actually shared. So I had to unify that
somehow, and also make room for server-side logic so that I could decide
which Xinha's codebase to link to and which xinha_config.js to serve based
on a user preference. I didn't want to put *that* particular logic directly
into opencore, so there had to be some simple default behavior plus a story
for overriding it in an opencore plugin package.
So, there's now a view registered for all contexts called @@xinha-config.
It is expected to return an HTML snippet that, when inserted into a page,
will activate Xinha. The default version of this view renders our trusty
old snippet[3]. But it can be overridden to render anything; the "opt-in
xinha upgrade" plugin[4] for example figures out which version of Xinha to
serve based on a build.ini setting.
Within opencore-the-zope-package, this view's contents are injected into
wiki-edit views by server-side traversal[5].
To get the same snippet into wordpress pages, I rely on Deliverance. The
wordpress template for editing a blog post now just contains a marker <div
class="opencore_wysiwyg"> instead of a Xinha configuration[6]. The
deliverance.xml rules used by the libopencore frontend look for that marker
div in the response, and replace it with the snippet fetched from
@@xinha-config if it's present: [7]. That way wiki pages and blog posts are
both getting their Xinha configurations from the same source, and we don't
need to maintain two copies of that code or any logic that might evolve
around it.
In short, opencore-the-zope-package continues to function standalone, and
also now offers a "Xinha configuration server" which external components can
consume in a uniform way by leaving a signal for the Deliverance frontend.
And any given OpenCore site can implement its own custom Xinha configuration
policy by developing a plugin package that overrides the default behavior.
Lastly .. I think this opens the door for a few other interesting
possibilities, which I haven't explored at all yet:
* Since the @@xinha-config view is registered on all contexts, it should be
possible to provide different Xinha configurations based on what type of
thing is being edited -- e.g. blog posts vs wiki pages vs mailing list
posts, etc, or even different types of wiki pages marked with different
marker interfaces.
* There's nothing Xinha-specific about the this architecture other than the
name "xinha-config" (which I may change prior to the 0.19 release) -- the
only explicit contract is "HTML to be injected into pages (with edit forms)"
and the implicit contract is "you should probably give back HTML that is
relevant to the user experience of filling out those edit forms." So a
plugin package could probably be developed easily to replace Xinha
altogether with TinyMCE or [your favorite editor here]. The only hitch I
expect would be whatever server-side views are needed for link & image
management, which aren't likely to use the same interfaces across all
client-side editors. But even that shouldn't be too much trouble.
[1] Currently the tickets I've submitted upstream are:
* http://trac.xinha.org/ticket/1541
* http://trac.xinha.org/ticket/1534
* http://trac.xinha.org/ticket/1535
* http://trac.xinha.org/ticket/1536
* http://trac.xinha.org/ticket/1537
* http://trac.xinha.org/ticket/1538
[2]
https://svn.openplans.org/svn/oc-js/trunk/opencore/js/thirdparty/xinha96r1270/
[3]
https://projects.openplans.org/opencore/browser/opencore/trunk/opencore/xinha/xinha.ptand
https://projects.openplans.org/opencore/browser/opencore/trunk/opencore/xinha/view.py
[4]
https://projects.openplans.org/opencore/browser/opencore/plugins/optinxinhaupgrade/trunk/optinxinhaupgrade
[5]
https://projects.openplans.org/opencore/browser/opencore/trunk/opencore/nui/wiki/wiki-edit-xinha.pt#L27
[6]
https://projects.openplans.org/opencore/changeset/27454/vendor/wordpress-mu/openplans
[7]
https://projects.openplans.org/opencore/changeset?new=27452%40opencore%2Flibopencore%2Ftrunk%2Flibopencore%2Fdeliverance.xml&old=26465%40opencore%2Flibopencore%2Ftrunk%2Flibopencore%2Fdeliverance.xml--
this requires the unreleased Deliverance 0.4-dev for the
"collapse-sources" setting,
https://projects.openplans.org/deliverance/ticket/44
--
Archive: http://www.coactivate.org/projects/opencore/lists/opencore-dev/archive/2010/09/1283636838104
To unsubscribe send an email with subject "unsubscribe" to opencore-dev-***@public.gmane.org Please contact opencore-dev-manager-81qHHgoATdGNjXQcXLqYpGD2FQJk+8+***@public.gmane.org for questions.
a very old version, I think our vendorbranch is cut from Xinha's 0.92b. The
latest release is 0.96(.2) -- and Xinha has supported Safari and Opera since
0.95.
CoActivate.org is now running the 0.96.2 codebase optionally, for people who
want to beta-test it. (If you're a user on CoActivate.org and want to help
test, ping me and I'll set up your account for it.)
I've been extracting the scattered changes we've made on our old
vendorbranch, and am submitting them upstream[1]. I've cut a new
vendorbranch from Xinha's latest ***@r1270 and have applied my upstream
patches there[2]. A few things remain to be extracted - most importantly,
the logic that prevents creation of hyperlinks within ((wicked link text)).
So, we'll definitely be able to ship with at least some flavor of Xinha
0.96+ by the time of opencore's 0.19 release. After the upgrade has settled
I'm also hoping to start adding some more plugins to the configuration, and
perhaps develop some new plugins too, including some opencore-specific ones
like "link to a project" or "click to contact a user."
== Internal details ==
I refactored and rearchitected some things in order to support
CoActivate.org's per-user opt-in upgrade. The biggest hitch was that,
previously, opencore wiki pages and wordpress blog posts were each serving
their own copies of the Xinha configuration. They were rendering the same
JavaScript code, but it wasn't actually shared. So I had to unify that
somehow, and also make room for server-side logic so that I could decide
which Xinha's codebase to link to and which xinha_config.js to serve based
on a user preference. I didn't want to put *that* particular logic directly
into opencore, so there had to be some simple default behavior plus a story
for overriding it in an opencore plugin package.
So, there's now a view registered for all contexts called @@xinha-config.
It is expected to return an HTML snippet that, when inserted into a page,
will activate Xinha. The default version of this view renders our trusty
old snippet[3]. But it can be overridden to render anything; the "opt-in
xinha upgrade" plugin[4] for example figures out which version of Xinha to
serve based on a build.ini setting.
Within opencore-the-zope-package, this view's contents are injected into
wiki-edit views by server-side traversal[5].
To get the same snippet into wordpress pages, I rely on Deliverance. The
wordpress template for editing a blog post now just contains a marker <div
class="opencore_wysiwyg"> instead of a Xinha configuration[6]. The
deliverance.xml rules used by the libopencore frontend look for that marker
div in the response, and replace it with the snippet fetched from
@@xinha-config if it's present: [7]. That way wiki pages and blog posts are
both getting their Xinha configurations from the same source, and we don't
need to maintain two copies of that code or any logic that might evolve
around it.
In short, opencore-the-zope-package continues to function standalone, and
also now offers a "Xinha configuration server" which external components can
consume in a uniform way by leaving a signal for the Deliverance frontend.
And any given OpenCore site can implement its own custom Xinha configuration
policy by developing a plugin package that overrides the default behavior.
Lastly .. I think this opens the door for a few other interesting
possibilities, which I haven't explored at all yet:
* Since the @@xinha-config view is registered on all contexts, it should be
possible to provide different Xinha configurations based on what type of
thing is being edited -- e.g. blog posts vs wiki pages vs mailing list
posts, etc, or even different types of wiki pages marked with different
marker interfaces.
* There's nothing Xinha-specific about the this architecture other than the
name "xinha-config" (which I may change prior to the 0.19 release) -- the
only explicit contract is "HTML to be injected into pages (with edit forms)"
and the implicit contract is "you should probably give back HTML that is
relevant to the user experience of filling out those edit forms." So a
plugin package could probably be developed easily to replace Xinha
altogether with TinyMCE or [your favorite editor here]. The only hitch I
expect would be whatever server-side views are needed for link & image
management, which aren't likely to use the same interfaces across all
client-side editors. But even that shouldn't be too much trouble.
[1] Currently the tickets I've submitted upstream are:
* http://trac.xinha.org/ticket/1541
* http://trac.xinha.org/ticket/1534
* http://trac.xinha.org/ticket/1535
* http://trac.xinha.org/ticket/1536
* http://trac.xinha.org/ticket/1537
* http://trac.xinha.org/ticket/1538
[2]
https://svn.openplans.org/svn/oc-js/trunk/opencore/js/thirdparty/xinha96r1270/
[3]
https://projects.openplans.org/opencore/browser/opencore/trunk/opencore/xinha/xinha.ptand
https://projects.openplans.org/opencore/browser/opencore/trunk/opencore/xinha/view.py
[4]
https://projects.openplans.org/opencore/browser/opencore/plugins/optinxinhaupgrade/trunk/optinxinhaupgrade
[5]
https://projects.openplans.org/opencore/browser/opencore/trunk/opencore/nui/wiki/wiki-edit-xinha.pt#L27
[6]
https://projects.openplans.org/opencore/changeset/27454/vendor/wordpress-mu/openplans
[7]
https://projects.openplans.org/opencore/changeset?new=27452%40opencore%2Flibopencore%2Ftrunk%2Flibopencore%2Fdeliverance.xml&old=26465%40opencore%2Flibopencore%2Ftrunk%2Flibopencore%2Fdeliverance.xml--
this requires the unreleased Deliverance 0.4-dev for the
"collapse-sources" setting,
https://projects.openplans.org/deliverance/ticket/44
--
Archive: http://www.coactivate.org/projects/opencore/lists/opencore-dev/archive/2010/09/1283636838104
To unsubscribe send an email with subject "unsubscribe" to opencore-dev-***@public.gmane.org Please contact opencore-dev-manager-81qHHgoATdGNjXQcXLqYpGD2FQJk+8+***@public.gmane.org for questions.