[geeklog-devel] Story Templates (was Re: About the "internal" and Webservices APIs)

[Joe Mucchiello]

At 01:47 PM 8/11/2007, Oliver Spiesshofer wrote:
>Joe,
>
>To write the whole thing, you should store several templates in the 
>database to accommodate different purposes for each content type, 
>and make a template-flag in the database to store them, so you need 
>code to upgrade the plugins and the stories tables. You would need a 
>list-function that allows the creator of content to choose from 
>several templates, so you need to rewrite the list-function of each 
>plugin, the edit-code, write a small documentation etc.

No, you should store control data in the database. The actual 
templates should be stored on the disk so you can use the existing 
template library to perform the variable substitutions. Geeklog has a 
template library. You are proposing adding templates to objects. Why 
wouldn't you use the existing template library?

>Your code does something I could include in my site code, and it 
>does the same as the simple textfile in which I currently store that 
>text - but in a much more complicated way. But it is nothing that 
>would ever see the core code of the next version.

Actually, I don't think anything but stories needs your templates and 
thus would prefer my version over a huge plugin interface. But 
besides that, ultimately my 10 lines of code are the core of your 
proposal. Everything else is just gloss. Selecting which template 
goes with the story is a dropdown in the story editor. Remember the 
first line of my code was commented "or however you want to find the 
template". You want to put the filename in the database. Have fun. 
That table only needs a few fields "name", "filename", perms 
(optional), maybe a hits counter. The story table gets a template 
field that holds the name.

>I am discussing here if it would be good to implement a new, simple 
>but convenient feature, and if that would also help with the webservices API.

I still see no connection here to webservices. But that's not really important.

>Please do not take what I write in the wrong way - I appreciate your 
>readiness to always provide sample code for your explanations - but 
>the discussion i wanted to start was about extending the gl 
>functionality, not asking for help on how to write a small hack.

Fine. I've already said I don't think it needs to be a global 
function and should be limited to stories. Here's why: polls, links 
and calendar objects are already very modular in the database and 
modifying their thtml files should be enough to handle just about 
anything you want to do with them. Stories only need it because the 
introtext/bodytext has no structure. Comments certainly don't need 
it. Staticpages might find it useful. But still, that's only two 
places it could be used and since one is a plugin and one isn't, a 
plugin API is not optimal here. (When will stories become a plugin? A 
rant for a different time. Just think though how much special code 
exists in the core to handle stories with them being a plugin that 
could go away.)

Why not write this idea as a plugin? It would work exactly like the 
Ratings plugin. You use PLG_templatesetvars and PLG_saveItem to hook 
the story and staticpage editor screens. The user has to add 
{template_options} to the appropriate thtml files. Your database 
table is "cid, templatename". When PLG_templatesetvars is called for 
viewing stories or staticpages. You run my 10 lines of code against 
$T->get_var('body_text') and call $T->set_var('body_text') with the result.

Those of us out here is user land have to do things this way. Just 
because you have CVS access doesn't mean you should just checkin 
anything you feel like. I'm not saying you do that Oliver, I'm just 
saying there is nothing about your proposal that makes it better than 
the ratings plugin. But the ratings plugin isn't supported by core 
and every upgrade people using that plugin have to put that 
ratings_option tag into every thtml file they want ratings to exist 
in. (OOo, an idea. See next email...) So while porting a hack from 
version to version can be difficult, porting an extension from 
version to version is just annoying. But your proposal isn't any more 
core-worthy than the ratings plugin, really.

I should move this to another thread but I'm lazy. This is not really 
directed at Oliver but at the whole core team. Where is the Geeklog 
roadmap? How are decisions about adding core functionality made? Is 
there a list of projects for 1.4.2? 1.4.3? 1.5? Is there any 
architectural guidance? Should Oliver write his idea into the core or 
should he write a plugin? Who decides? Roadmaps are prominently 
displayed on most OSS webpages. Geeklog's page is completely silent about it.


----
Joe Mucchiello
Throwing Dice Games
http://www.throwingdice.com