On Jun 10, 2007, at 2:59 AM, Martin Fick wrote:
On Friday 08 June 2007 06:52:44 pm Crisses wrote:
On Jun 3, 2007, at 3:53 AM, Martin Fick wrote:
I would like to announce the new Content recipe:
http://www.pmwiki.org/wiki/Cookbook/Content
This recipe is an API and is not useful to you unless: you are a
recipe developer or you use another recipe which requires this
recipe.
...
"Content" is not descriptive enough.
Fair enough. :) I am open to suggestions, it is a little difficult
since it
is an API. Maybe it should have been ContentAPI?
That's a tough one to name :) Content API is closer. Content
Control API? The words Content Management API would put it too close
to CMS and give it strange connotations.
- Maybe a fancy font text generator, remember the 90s when people
used gifs to
create custom fonts? :)
Actually, there's still a call to do something like this for
navigation, and headlines. If you look at CSS Zen Garden, and you
start dreaming a lot -- then realize PmWiki can't DO that....because
of a lack of font flexibility in HTML.... you start thinking maybe a
judicious text image spawned by PmWiki here and there wouldn't be so
bad. ;)
- An electrical circuit (schematic) illustrator
THAT would interest my partner (RF electrical engineer)
- Game illustrators, for example a soccer coaching tool that
displays field
layouts. Maybe even a billiards illustrator.
visual chess board layouts from the ascii chess notation (I don't
know the name of it)!! I can see Patrick doing this yesterday ;)
Oh, look, he already did! ;)
- A class file compiler for coding java applets directly in a wiki
page.
eeevil ;)
LOL
So can you embed objects with this? Because there's also some
interesting XXX->swf applications out there. You can make small
flash apps on the fly (Patrick -> slideshows!!). That would make a
strange bedfellow for PmWiki, but it's very do-able.
Patrick had mentioned wanting to make slideshows with PmWiki.... I
dislike flash splashpages, hate flash navigation, but I see merit in
flash as a cross-platform/browser presentation/slideshow mechanism.
Example: would this be helpful to the wiki->pdf recipes?
As you mentioned, the PDF export recipe would be a good candidate
for this.
With the content API this could be enhanced so that individual
sections of
pages could be used to create PDFs instead of only entire pages.
But another
enhancement would be to easily create other export types from the PDF,
perhaps converting the PDF to PS.
Someone had mentioned to me that every time PmWiki came up with new
markup, a pdf output recipe had to be updated to render said markup
properly in a print format... I don't think your API would change
that work...but would it make it any easier?
Conceptually this could also be reversed though, a recipe could be
written
that allows CSV data to be written in a wiki page and surrounded by
a csv
directive which would then create a CSV link for easy CSV downloading.
That's interesting.
Admittetly if you just wanted a markup to turn CSV into "Simple
Tables" you
would be better off just creating a markup rule to do that. The
reason that
you might opt instead to use some of the content mechanisms to do
this is if
you want easy export functionality of that CSV, or if you also
wanted to use
the CSV data in other ways, for example to create a graph.
Actually tables as an image would sometimes be nice.... the data
would still be there, and be searchable, I would think, which makes
it a presentation win/win, unlike exporting an image from an
Illustrator/Excel/etc. graph/table.
Some other existing recipes that I think could benefit from the same
advantages, some more than others (this is a rough guess, these may
or may
not be appropriate):
http://www.pmwiki.org/wiki/Cookbook/SourceBlock
I think for this one you'd still want to be able to select & copy
text....creating a beautified image loses some appeal for
sourcecode. Or did you mean to use this to export to a text-
processing app, and return to the wiki as coded text?
http://www.pmwiki.org/wiki/Cookbook/Comments
Comments?
http://www.pmwiki.org/wiki/Cookbook/ICalExport
That's an interesting one.... actually I was thinking iCalendar->wiki
and wiki->iCalendar format recently. Also been thinking about
vCards. There's not much difference between the formats, when you
look at the RFCs (and in fact, i think they're compatible on purpose).
The Network Effect
What's interesting is that once a few converters are created and
various base
type are defined, independent recipes should start to grow more
capabilities
transparently since new export types could potentially become
available to
them.
I don't get how changes to the base would change how the recipes use
them.
If we add a new (:greenpigs:) markup, and someone updates the API so
that it throughputs (:greenpigs:) how does that tell the PDF
generator how to make (:greenpigs:) look on the output end? Someone
would have to update the PDF renderer to display (:greenpigs:) in a
print format.
Now, if someone wanted to create an OGG output based on your ASCII
music notation->midi, I could see how that might help...
I envision that the auto conversion properties of this recipe could
benefit from a "network effect". Each base type and output type
adds to the
network as a whole and the network of types becomes greater than
the sum of
the whole. But that is just fantasy for now. :)
Well chess layouts are still chess layouts. Ascii music notation
rendered as chess layouts might be interesting (or just fail). :) It
might be easier to render a chessboard layout as music.
I know that I did not list a lot of examples
Actually, that was plenty examples. I'm sure there are more things
that you didn't think of, but it lets me know what direction your API
is aimed at. Human imagination can launch from there.
I have never liked the alternative solutions to
embedding images that most people have used: create an image on
disk an
reference it *2, create a separate script that is completely URL
driven *3.
Neither of these solutions is very extensible and they do not as
easily have
the potential for the network effect mentioned above.
I agree that those are not great options -- I certainly wasn't
complaining that you wrote an API :) I wanted a better explanation
of what it does, and what potential niches it fills.
Additionaly, there is
a lot of shared logic that both of these solutions could benefit
from and an
API makes this possible, as the API grows, any recipes using it
could grow
automatically too.
I actually love the idea of adding this capability, because I've been
doing a lot of data work. Data->CSV alone is doable by pagelist with
templates, but then you have to cut&paste it into a document. Having
another way to do it, with a downloadable, would be great.
*1 I implemented this with gnuplot and then realized that gnuplot
is not even
close to being safe to run from webspace.
Ewww. Probably OK if it's a closed edit wiki, but that sounds
dangerous.
Thanks!!
Crisses
_______________________________________________
pmwiki-devel mailing list
pmwiki-devel@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-devel
