[pmwiki-devel] New Recipe: Content

[Crisses]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/pmwiki-devel/attachments/20070610/5233f8e6/attachment-0001.html