You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Sjur Moshagen <sj...@mac.com> on 2009/08/18 11:16:17 UTC
ical output plugin - sitemap feedback wanted
Hello all,
For a long time our project group has been using an ical output
project module that I'm now converting to a real plugin, which I
intend to add to the whiteboard. For historical reasons, the url
pattern matched against presupposes a certain file naming scheme, as
follows:
<!-- Will match weekly meeting files {2}, and extract the tasks for
the
person in {3}, returning the task list as an iCal TODO list -->
<map:match pattern="**/Tasks_*_*.ics">
<map:generate src="cocoon://{1}/Meeting_{2}.xml" />
<map:transform src="{lm:ical.transform.document.ics}">
<map:parameter name="date" value="{2}" />
<map:parameter name="person" value="{3}" />
</map:transform>
<map:serialize type="ical" />
</map:match>
That is, the meeting date is encoded in the filename, and the person
for which the ical file should be created is encoded in the URL in
addition to the date. Also, the filename is fixed to the pattern
"Meeting_{DATE}.xml (or actually *.jspwiki in our case). Is this ok,
or should I change to a more general pattern? One reasoning is that it
doesn't make sense to create an ical file for a non-meeting document,
and this dependency is expressed in the URL and filename patterns. But
then again, the whole plugin depends on certain conventions in the
source document, so you can anyway add non-working links (ie link to
meeting documents that do not follow these conventions).
Comments on the URL or filename patterns? Other comments?
General note:
This is an excellent example of the flexibility and usefulness of
Forrest. We (a project team geographically distributed) have regular
meetings using voicechat software + a collaborative editor (usually
SubEthaEdit because we are on Macs, but Gobby will do fine), we write
in jspwiki format, ie structured, plain text (the KISS principle),
which is transformed by Forrest to online meeting memos (pdf, html)
and task lists in iCal format using the plugin described above.
Best regards,
Sjur
Re: ical output plugin - sitemap feedback wanted
Posted by Sjur Moshagen <sj...@mac.com>.
Den 30. okt. 2009 kl. 06.43 skrev David Crossley:
> Sjur Moshagen wrote:
>> skrev David Crossley:
>>> Sjur Moshagen wrote:
>>>> General note:
>>>>
>>>> This is an excellent example of the flexibility and usefulness of
>>>> Forrest. We (a project team geographically distributed) have
>>>> regular
>>>> meetings using voicechat software + a collaborative editor (usually
>>>> SubEthaEdit because we are on Macs, but Gobby will do fine), we
>>>> write
>>>> in jspwiki format, ie structured, plain text (the KISS principle),
>>>> which is transformed by Forrest to online meeting memos (pdf, html)
>>>> and task lists in iCal format using the plugin described above.
>>>
>>> This is very interesting. Thanks so much for sharing a
>>> situation for how you use Forrest. That should encourage.
>>
>> :)
>
> Many thanks for adding the initial iCal output plugin Sjur.
:)
> I had a quick look and it works for me.
Nice to hear.
> I did a few minor tweaks and house-keeping stuff.
I saw that, thanks a lot for cleaning the bits I didn't notice.
> There are some strange unreadable characters next to links
> in the *.jspwiki sample files.
Those are UTF-8 encoded non-breaking spaces (NBSP). The wiki parser
has some interesting whitespace processing - in some cases spaces are
inserted where there were none in the source (e.g. around boldface or
italic), in some cases spaces are removed, like after URL's, which
makes the following text run into the URL. NBSP is treated as a
regular character, and isn't touched, making the final output look
like intended.
We use only UTF-8, so I had forgotten to change it to Latin-1. It is
changed now.
I know the NBSP trick is really a hack, but I haven't had time to dig
into the wiki parser code. I'm not sure the present behaviour is
easily fixed.
> By the way, this new proposal at Apache Incubator might
> be of interest.
> [PROPOSAL] Apache OpenMeetings incubator for Web Conferencing
> http://markmail.org/message/aahmijcb5dsjlxiv
Thanks for the pointer.
Best,
Sjur
Re: ical output plugin - sitemap feedback wanted
Posted by David Crossley <cr...@apache.org>.
Sjur Moshagen wrote:
> skrev David Crossley:
> >Sjur Moshagen wrote:
> >>General note:
> >>
> >>This is an excellent example of the flexibility and usefulness of
> >>Forrest. We (a project team geographically distributed) have regular
> >>meetings using voicechat software + a collaborative editor (usually
> >>SubEthaEdit because we are on Macs, but Gobby will do fine), we write
> >>in jspwiki format, ie structured, plain text (the KISS principle),
> >>which is transformed by Forrest to online meeting memos (pdf, html)
> >>and task lists in iCal format using the plugin described above.
> >
> >This is very interesting. Thanks so much for sharing a
> >situation for how you use Forrest. That should encourage.
>
> :)
Many thanks for adding the initial iCal output plugin Sjur.
I had a quick look and it works for me.
I did a few minor tweaks and house-keeping stuff.
There are some strange unreadable characters next to links
in the *.jspwiki sample files.
By the way, this new proposal at Apache Incubator might
be of interest.
[PROPOSAL] Apache OpenMeetings incubator for Web Conferencing
http://markmail.org/message/aahmijcb5dsjlxiv
-David
Re: ical output plugin - sitemap feedback wanted
Posted by Sjur Moshagen <sj...@mac.com>.
Den 19. aug. 2009 kl. 16.30 skrev David Crossley:
>> General note:
>>
>> This is an excellent example of the flexibility and usefulness of
>> Forrest. We (a project team geographically distributed) have regular
>> meetings using voicechat software + a collaborative editor (usually
>> SubEthaEdit because we are on Macs, but Gobby will do fine), we write
>> in jspwiki format, ie structured, plain text (the KISS principle),
>> which is transformed by Forrest to online meeting memos (pdf, html)
>> and task lists in iCal format using the plugin described above.
>
> This is very interesting. Thanks so much for sharing a
> situation for how you use Forrest. That should encourage.
:)
> This is very timely for me. I need to help with forming a
> co-operative and they will need to conduct their first meeting
> of distributed members.
>
> I did a net search and found some of your explanations
> at divvun.no ...
Nice to know that our documentation is being read by someone:)
> will see what tips i can glean. Thanks.
You are welcome:)
One reason I'm turning this local adaption of Forrest into a plugin is
that it needs improvements. I had hoped that the improvement process
would benefit from feedback from the community - and this has already
happened in the form of the suggestion from Ross about using our xml
properties system (see the other reply in this thread). Also the
encouragement I get from the above comments helps a lot:)
Presently the ical plugin presupposes that all tasks are summarised in
the last section of the document. This makes it easy to parse, xml-
wise, but it has turned out to not work that well in the meetings. We
basically have to maintain a status of each task at two places: under
each topic we discuss, and at the end of the document.
I will try to enhance the plugin to be able to automacially extract
and collect all tasks for the relevant person directly from the
topics' todo lists. This will make the task summary at the end
superfluous - it is really only a reflection of my xsl capabilities
(and time constraints) at the time when I wrote the original code.
This enhancement will of course make the xsl code more complicated,
but it will support a more logical meeting flow, and also encourage
the use of the ical task lists by the team members. Up until now
several team members have just copied the list at the end of the
document, instead of using the ical feature. When there is no list to
copy, they *have to* use the ical task list;)
Another enhancement I plan is to add support for explicit deadlines
for each task. At the moment each task is given a default execution
time of one week, ie until the next meeting, which isn't very flexible.
Finally, I would like to be able to generate some sort of stable ID,
to make it possible to update tasks imported into calendaring apps. As
it is now, each time an ical task list is imported, all tasks are
added as new tasks, even though the majority of them are only updates
(or even copies) of already existing tasks. I'll see what is possible
within the limits of of the ical format.
Best regards,
Sjur
Re: ical output plugin - sitemap feedback wanted
Posted by Sjur Moshagen <sj...@mac.com>.
Den 19. aug. 2009 kl. 23.25 skrev Ross Gardler:
> 2009/8/19 David Crossley <cr...@apache.org>:
>>> Comments on the URL or filename patterns? Other comments?
>>
>> This is exiting. That seems like a fine approach to me.
>
> I agree that it's great to see some new work here.
:)
> I don't quite agree
> that the URL patterns is a "fine approach" though. But don't worry,
> it's a small change I am going to propose and it is backward
> compatible with your current scheme.
:)
> input.xmap:
>
> <map:match
> pattern
> ="{properties:daisy.pathPrefix}*{properties:daisy.fileExt}.xml">
> <map:call resource="daisy-to-document">
> <map:parameter name="docID" value="{1}"/>
> <map:parameter name="path" value="{0}"/>
> </map:call>
> </map:match>
>
> forrest.properties.xml:
>
> <property name="daisy.pathPrefix" value=""/>
> ...
> <property name="daisy.fileExt" value=".daisy"/>
>
> Now the project can override these properties in its local
> forrest.properties.xml if it needs to do so, or it can leave them at
> their defaults for the same behaviour as your existing sitemap.
Thanks for the suggestion and reminder about the xml properties, Ross.
I had completely forgotten about them, even though I used them
extensively in the work I did on the pdf output plugin.
This will also make it easy to add other properties for more
flexibility in other areas.
Best regards,
Sjur
Re: ical output plugin - sitemap feedback wanted
Posted by Ross Gardler <rg...@apache.org>.
2009/8/19 David Crossley <cr...@apache.org>:
> Sjur Moshagen wrote:
>> Hello all,
>>
>> For a long time our project group has been using an ical output
>> project module that I'm now converting to a real plugin, which I
>> intend to add to the whiteboard. For historical reasons, the url
>> pattern matched against presupposes a certain file naming scheme, as
>> follows:
>>
>> <!-- Will match weekly meeting files {2}, and extract the tasks for
>> the
>> person in {3}, returning the task list as an iCal TODO list -->
>> <map:match pattern="**/Tasks_*_*.ics">
>> <map:generate src="cocoon://{1}/Meeting_{2}.xml" />
>> <map:transform src="{lm:ical.transform.document.ics}">
>> <map:parameter name="date" value="{2}" />
>> <map:parameter name="person" value="{3}" />
>> </map:transform>
>> <map:serialize type="ical" />
>> </map:match>
>>
>> That is, the meeting date is encoded in the filename, and the person
>> for which the ical file should be created is encoded in the URL in
>> addition to the date. Also, the filename is fixed to the pattern
>> "Meeting_{DATE}.xml (or actually *.jspwiki in our case). Is this ok,
>> or should I change to a more general pattern? One reasoning is that it
>> doesn't make sense to create an ical file for a non-meeting document,
>> and this dependency is expressed in the URL and filename patterns. But
>> then again, the whole plugin depends on certain conventions in the
>> source document, so you can anyway add non-working links (ie link to
>> meeting documents that do not follow these conventions).
>>
>> Comments on the URL or filename patterns? Other comments?
>
> This is exiting. That seems like a fine approach to me.
I agree that it's great to see some new work here. I don't quite agree
that the URL patterns is a "fine approach" though. But don't worry,
it's a small change I am going to propose and it is backward
compatible with your current scheme.
Basically, some time ago we decided that fixed url patterns were a bad
idea since it creates potential clashes in peoples applications. We
therefore implemented the new (although not officially released) XML
properties system to allow the sitemap to be easily configured without
having to edit the plugin files (actually that was a side effect, but
that's not relevant right now).
You can see an example of this approach in use in the Daisy input
plugin (whiteboard):
input.xmap:
<map:match
pattern="{properties:daisy.pathPrefix}*{properties:daisy.fileExt}.xml">
<map:call resource="daisy-to-document">
<map:parameter name="docID" value="{1}"/>
<map:parameter name="path" value="{0}"/>
</map:call>
</map:match>
forrest.properties.xml:
<property name="daisy.pathPrefix" value=""/>
...
<property name="daisy.fileExt" value=".daisy"/>
Now the project can override these properties in its local
forrest.properties.xml if it needs to do so, or it can leave them at
their defaults for the same behaviour as your existing sitemap.
Ross
Re: ical output plugin - sitemap feedback wanted
Posted by David Crossley <cr...@apache.org>.
Sjur Moshagen wrote:
> Hello all,
>
> For a long time our project group has been using an ical output
> project module that I'm now converting to a real plugin, which I
> intend to add to the whiteboard. For historical reasons, the url
> pattern matched against presupposes a certain file naming scheme, as
> follows:
>
> <!-- Will match weekly meeting files {2}, and extract the tasks for
> the
> person in {3}, returning the task list as an iCal TODO list -->
> <map:match pattern="**/Tasks_*_*.ics">
> <map:generate src="cocoon://{1}/Meeting_{2}.xml" />
> <map:transform src="{lm:ical.transform.document.ics}">
> <map:parameter name="date" value="{2}" />
> <map:parameter name="person" value="{3}" />
> </map:transform>
> <map:serialize type="ical" />
> </map:match>
>
> That is, the meeting date is encoded in the filename, and the person
> for which the ical file should be created is encoded in the URL in
> addition to the date. Also, the filename is fixed to the pattern
> "Meeting_{DATE}.xml (or actually *.jspwiki in our case). Is this ok,
> or should I change to a more general pattern? One reasoning is that it
> doesn't make sense to create an ical file for a non-meeting document,
> and this dependency is expressed in the URL and filename patterns. But
> then again, the whole plugin depends on certain conventions in the
> source document, so you can anyway add non-working links (ie link to
> meeting documents that do not follow these conventions).
>
> Comments on the URL or filename patterns? Other comments?
This is exiting. That seems like a fine approach to me.
> General note:
>
> This is an excellent example of the flexibility and usefulness of
> Forrest. We (a project team geographically distributed) have regular
> meetings using voicechat software + a collaborative editor (usually
> SubEthaEdit because we are on Macs, but Gobby will do fine), we write
> in jspwiki format, ie structured, plain text (the KISS principle),
> which is transformed by Forrest to online meeting memos (pdf, html)
> and task lists in iCal format using the plugin described above.
This is very interesting. Thanks so much for sharing a
situation for how you use Forrest. That should encourage.
This is very timely for me. I need to help with forming a
co-operative and they will need to conduct their first meeting
of distributed members.
I did a net search and found some of your explanations
at divvun.no ... will see what tips i can glean. Thanks.
-David