You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jspwiki.apache.org by Brian Burch <br...@PingToo.com> on 2009/02/24 21:39:22 UTC
seeding content in pages not yet created
I've been following a couple of recent threads on related topics. I've
also read the documentation on processing flow and looked quite closely
at the code. I suspect this is a relatively common requirement and want
to be sure I am using (or coding) the most appropriate solution.
After exploring ImagePlugin and SlideShowPlugin, I decided neither
suited my problem well enough. I also feel that uploading images to my
wiki is not appropriate, given the way I manage my photo collection as a
file system directory tree on the same machine as my wiki.
I have already written, but not yet completely generalised my own
PhotoCollectionPlugin (yes, it does have its own junit test suite!) It
assumes the jspWiki webapp has direct access (or via a symlink) to a
hierarchical directory structure that holds a photo collection.
My idea is to incorporate my existing digital photograph collection into
my wiki. The directory structure already provides the components of the
wiki page names and titles, thus immediately seeding the search engine
with important keywords, such as the year, month/season or holiday
location. As and when me and my family have the enthusiasm, we can then
add narrative to a wiki page associated with each individual
subdirectory or photo, thus enhancing the richness of our "searchscape".
In other words, one only needs to manually create a page for the "root"
of the photo collection and insert a call to my plugin. From that simple
start, the wiki has the potential to "grow" throughout the photo
collection as users choose to create new wiki pages. At the same time,
new photo directories and images can be added and will immediately
become "potential" new wiki pages.
At this stage of the development, I manually insert plugin statements to
associate a particular wiki page with a particular node or leaf. If the
target is a photo, the plugin can insert a thumbnail as well as the
hyperlink. If the target wiki page already exists, the plugin generates
a standard Wiki.jsp hyperlink to that page. On the other hand, if the
photo (or directory) exists, but the corresponding wiki page does not,
then the hyperlink calls Edit.jsp to create it when/if the link is
eventually followed.
Manual insertion of these plugin statements is tedious and error-prone,
so only suitable for development. My plugin already knows exactly what
should be inserted when it would be (quasi-recursively) called at the
time of creating the new wiki page, so there is no need to involve the
end user in this crucial operation of "wiring" the photo collection
structure into the wiki.
In the ideal world (where is that, by the way...?) I would pass my
generated plugin statement for the target page as a parameter in the
url, something along these lines (line breaks inserted for clarity):
<div><a class="createpage"
href="/wiki/Edit.jsp?
page=FilesPictures2001P2170018.JPG&
insertText=[{INSERT PhotoCollectionPlugin photodir='/2001/P2170019.JPG'}]"
title="Create "Files Pictures 2001 P2170018.JPG"">Files
Pictures 2001 P2170018.JPG</a>.</div>
i.e., following this hyperlink would trigger the creation of the new
wiki page, pre-seeded with the correct plugin invocation to "wire up"
the underlying image file or directory.
My problem is how best to intercept the page creation event and use the
generated jsp parameter value to insert a wiki text string "as if" the
user had decided to type it and save the contents?
I've looked at wiki variables, but don't see how to use them in my
situation.
I've looked at writing my own template, but this doesn't feel like the
best approach - I am not trying to change the look and feel of every
single page in my wiki - only to feed knowledge from an existing wiki
page of "a special kind" into a related-but-yet-to-exist wiki page of
the "same kind".
Janne's recent tip about writing a Filter seems more suitable and I'm
not afraid of writing java code. However, it feels wrong for me to be
writing code specifically for my plugin that ought to be generally
useful... i.e. to watch for the presence of a jsp command parameter and
insert its value into the initial content of a new wiki page.
Have I overlooked something obvious? Suggestions would be very welcome -
especially before I start writing more code!
Regards,
Brian
p.s. thanks for the impressive project! It is hard to take the whole
thing in and make sense of it because I wasn't aware of it earlier in
its development life.
Re: seeding content in pages not yet created
Posted by Quinn Fissler <qf...@gmail.com>.
Did someone say 3.0 ? :-)
2009/2/25 Janne Jalkanen <ja...@ecyrd.com>
>
>> Why do you feel _editedtext should not be an officially supported feature?
>> Is there a better way to do something similar, or are you hoping to develop
>> something better in the future?
>>
>
> It only works with the current incarnation of the plain editor. If you use
> FCK, the parameter is different.
>
> Because it is a part of JSPWiki internals, it's currently not officially
> supported or documented. My comment should not be taken as a value
> judgement as to its potential worthiness as an official supported feature
> later on. I was just simply stating a fact of its current level of support.
> If we want to make it an officially supported feature, I think it needs a
> bit more discussion as to whether this is the correct way.
>
> But it's stayed the same for the last three major versions, and is not seen
> to change in 3.0 either.
>
> /Janne
Re: seeding content in pages not yet created
Posted by Janne Jalkanen <ja...@ecyrd.com>.
>
> Why do you feel _editedtext should not be an officially supported
> feature? Is there a better way to do something similar, or are you
> hoping to develop something better in the future?
It only works with the current incarnation of the plain editor. If you
use FCK, the parameter is different.
Because it is a part of JSPWiki internals, it's currently not
officially supported or documented. My comment should not be taken as
a value judgement as to its potential worthiness as an official
supported feature later on. I was just simply stating a fact of its
current level of support. If we want to make it an officially
supported feature, I think it needs a bit more discussion as to
whether this is the correct way.
But it's stayed the same for the last three major versions, and is not
seen to change in 3.0 either.
/Janne
Re: seeding content in pages not yet created
Posted by Brian Burch <br...@PingToo.com>.
Janne Jalkanen wrote:
>
> Using _editedtext as a HTTP parameter should work. As in
>
> http://sandbox.jspwiki.org/Edit.jsp?page=About&_editedtext=Foobar
Thanks very much for the tip, Janne. That is a much simpler solution to
my problem. I tried your example with a mockup of my text, and the saved
paged tried to execute my plugin, so I am happy that I can use the feature.
> However, this is not guaranteed to work in future versions of JSPWiki!
> But it is improbable that it would break either.
I am being lazy because I am away from home and don't have the jspWiki
source with me... but I do not remember seeing Edit.jsp handling the
_editedtext parameter when I was trying to follow the execution flow.
Why do you feel _editedtext should not be an officially supported
feature? Is there a better way to do something similar, or are you
hoping to develop something better in the future?
Regards,
Brian
Re: seeding content in pages not yet created
Posted by Janne Jalkanen <ja...@ecyrd.com>.
Using _editedtext as a HTTP parameter should work. As in
http://sandbox.jspwiki.org/Edit.jsp?page=About&_editedtext=Foobar
However, this is not guaranteed to work in future versions of JSPWiki!
But it is improbable that it would break either.
/Janne
On 24 Feb 2009, at 22:39, Brian Burch wrote:
> I've been following a couple of recent threads on related topics.
> I've also read the documentation on processing flow and looked quite
> closely at the code. I suspect this is a relatively common
> requirement and want to be sure I am using (or coding) the most
> appropriate solution.
>
> After exploring ImagePlugin and SlideShowPlugin, I decided neither
> suited my problem well enough. I also feel that uploading images to
> my wiki is not appropriate, given the way I manage my photo
> collection as a file system directory tree on the same machine as my
> wiki.
>
> I have already written, but not yet completely generalised my own
> PhotoCollectionPlugin (yes, it does have its own junit test suite!)
> It assumes the jspWiki webapp has direct access (or via a symlink)
> to a hierarchical directory structure that holds a photo collection.
>
> My idea is to incorporate my existing digital photograph collection
> into my wiki. The directory structure already provides the
> components of the wiki page names and titles, thus immediately
> seeding the search engine with important keywords, such as the year,
> month/season or holiday location. As and when me and my family have
> the enthusiasm, we can then add narrative to a wiki page associated
> with each individual subdirectory or photo, thus enhancing the
> richness of our "searchscape".
>
> In other words, one only needs to manually create a page for the
> "root" of the photo collection and insert a call to my plugin. From
> that simple start, the wiki has the potential to "grow" throughout
> the photo collection as users choose to create new wiki pages. At
> the same time, new photo directories and images can be added and
> will immediately become "potential" new wiki pages.
>
> At this stage of the development, I manually insert plugin
> statements to associate a particular wiki page with a particular
> node or leaf. If the target is a photo, the plugin can insert a
> thumbnail as well as the hyperlink. If the target wiki page already
> exists, the plugin generates a standard Wiki.jsp hyperlink to that
> page. On the other hand, if the photo (or directory) exists, but the
> corresponding wiki page does not, then the hyperlink calls Edit.jsp
> to create it when/if the link is eventually followed.
>
> Manual insertion of these plugin statements is tedious and error-
> prone, so only suitable for development. My plugin already knows
> exactly what should be inserted when it would be (quasi-recursively)
> called at the time of creating the new wiki page, so there is no
> need to involve the end user in this crucial operation of "wiring"
> the photo collection structure into the wiki.
>
> In the ideal world (where is that, by the way...?) I would pass my
> generated plugin statement for the target page as a parameter in the
> url, something along these lines (line breaks inserted for clarity):
>
> <div><a class="createpage"
> href="/wiki/Edit.jsp?
> page=FilesPictures2001P2170018.JPG&
> insertText=[{INSERT PhotoCollectionPlugin photodir='/2001/
> P2170019.JPG'}]"
> title="Create "Files Pictures 2001 P2170018.JPG"">Files
> Pictures 2001 P2170018.JPG</a>.</div>
>
> i.e., following this hyperlink would trigger the creation of the new
> wiki page, pre-seeded with the correct plugin invocation to "wire
> up" the underlying image file or directory.
>
> My problem is how best to intercept the page creation event and use
> the generated jsp parameter value to insert a wiki text string "as
> if" the user had decided to type it and save the contents?
>
> I've looked at wiki variables, but don't see how to use them in my
> situation.
>
> I've looked at writing my own template, but this doesn't feel like
> the best approach - I am not trying to change the look and feel of
> every single page in my wiki - only to feed knowledge from an
> existing wiki page of "a special kind" into a related-but-yet-to-
> exist wiki page of the "same kind".
>
> Janne's recent tip about writing a Filter seems more suitable and
> I'm not afraid of writing java code. However, it feels wrong for me
> to be writing code specifically for my plugin that ought to be
> generally useful... i.e. to watch for the presence of a jsp command
> parameter and insert its value into the initial content of a new
> wiki page.
>
> Have I overlooked something obvious? Suggestions would be very
> welcome - especially before I start writing more code!
>
> Regards,
>
> Brian
>
> p.s. thanks for the impressive project! It is hard to take the whole
> thing in and make sense of it because I wasn't aware of it earlier
> in its development life.