dglee87 / get-simple-cms

Automatically exported from code.google.com/p/get-simple-cms
GNU General Public License v3.0
0 stars 0 forks source link

Introducing a new themeing function. #12

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
The theme function get_page_content() should be allowed to have one
argument. This argument being a page slug.

If no argument passed to the function, it should return an echo of the
content of the current page.
If an existing slug is passed as argument, it should return an echo of the
content of the page known by said slug.
If a non-existing slug is passed as argument, it should return FALSE.

For more information on the idea:
http://get-simple.info/forum/viewtopic.php?pid=1574#p1574

Original issue reported on code.google.com by martijn.personal@gmail.com on 2 Jan 2010 at 12:49

GoogleCodeExporter commented 9 years ago
I like this idea. Great idea Martijn

Original comment by ccagle8 on 2 Jan 2010 at 1:28

GoogleCodeExporter commented 9 years ago
Even better if we could pass an array of what we want back 
from the page. 
E.g. Get the title,content and the pubdate. 
You just know someones gonna ask for it sometime. Might as 
well deal with it now.

What do you think? 

Original comment by MichaelS...@gmail.com on 2 Jan 2010 at 2:36

GoogleCodeExporter commented 9 years ago
I like it, but wouldn’t that mean we’re rewriting all the theme functions 
as we know
them? Currently we have different functions for all these things. What you 
suggest
would be something like:

get_page_data('slug','pubdate') => gives pubDate of the page called slug.
get_page_data('slug',['pubdate','title']) => returns an object containing 
pubDate and
title of the page called slug.

Is that what you meant Mike?

Also, this will disable the ability to directly echo the data into the 
template. A
thing, I believe, many non-coders like about our template syntax. Should a
get_page_data() for only 1 thing echo it? But when we pass an array it 
doesn’t echo
any more. This could get confusing, I think it will need some thinking.

Original comment by martijn.personal@gmail.com on 2 Jan 2010 at 2:47

GoogleCodeExporter commented 9 years ago
we could split it as some of the functions already do. 

get_page_data(slug,item) to echo 1 item from the page. Default to content.  
return_page_date(slug,[items]) to return 1 or more items from the page. Default 
to 
content.

That way we cover both scenarios. 

Mike.

Original comment by MichaelS...@gmail.com on 2 Jan 2010 at 8:08

GoogleCodeExporter commented 9 years ago
True, I think splitting into a get_ and return_ function is a good idea 
nevertheless.
I already did this myself in my theme’s function.php to allow certain checks 
on the
content to be run by PHP.

I rewrote my whole proposition for new theme functions and attached it as a text
file. Please look at it and give your opinions.

Original comment by martijn.personal@gmail.com on 2 Jan 2010 at 9:16

Attachments:

GoogleCodeExporter commented 9 years ago
Yeah thats looks good. Should work a treat. 

Rather than limit the allowed <data child>, I'd just return null if it doesn't 
exist. 

I'm working on a plugin which allows theme developers to add extra children 
without 
having to manually change the backend. That way your functions will still 
function. 
Also means you don't have to update the function if/when any new fields get 
added. 

I'll send you a mail with a demo. 

Mike... 

Original comment by MichaelS...@gmail.com on 2 Jan 2010 at 9:34

GoogleCodeExporter commented 9 years ago
Sounds OK Mike. Question though, should it return null or FALSE when the item is
undefined? As I see it, there is a difference between those two. I would want 
to go
for FALSE as it makes checking for existence easier.

Being able to add extra fields sounds interesting. Anything that could be 
implemented
in GetSimple itself? You might want to create an issue for it and take the 
discussion
separate from here.

Original comment by martijn.personal@gmail.com on 2 Jan 2010 at 9:46

GoogleCodeExporter commented 9 years ago
I would probably go for Null, False will only be used for debugging and the 
initial 
design of the theme. Once fixed you wont check for it again. 

Each page as it stands has all 11 options there at the moment. They have to be 
there 
whether you set them or not. 

Original comment by MichaelS...@gmail.com on 2 Jan 2010 at 11:58

GoogleCodeExporter commented 9 years ago
So this function would essentially take the place of almost every template echo 
currently in place? Sounds a little like overkill. I liked the idea of changing 
get_page_content() to check if a slug is given, but not adding a new function 
all 
together unless someone sees a time where only the new function would do.

Also, maybe an even better solution would be to change all functions to accept 
a 
page_id optionally that will echo/return a different page's content if passed. 
That 
way, we aren't really adding anything new.  

Original comment by ccagle8 on 3 Jan 2010 at 1:35

GoogleCodeExporter commented 9 years ago
Well, if we adopt Mike’s additional fields into the core we will need a 
function that
can access any possible field. Which is what I am suggesting. That is also “a 
time
where only the new function would do.”

As it stands now, we might bloat the code more adding the optional slug 
argument to
each function and then rewriting them to offer both return_ and get_ variants 
than
when we simply take them all out and introducing this one new function.

If you want to have backwards compatibility all currently known functions can be
added at the bottom, as kind of wrappers for this function? That way all older 
themes
will keep functioning while new themes can have more power over their content.

Original comment by martijn.personal@gmail.com on 3 Jan 2010 at 1:45

GoogleCodeExporter commented 9 years ago
I like the idea of the existing functions using this new get-all function. That 
will 
surely cut down on the code bloat and reduce duplicated code. 

I like Mike's ability to add new fields into the edit panel, but I'm thinking 
that we 
use this as a test case scenario to create an extensible plugin system. Using 
XML 
files are not developer friendly and I like just being able to "add" a function 
to a 
"hook" that is placed in the edit area. Wordpress does this very well with 
Actions: 
http://codex.wordpress.org/Plugin_API#Actions

Mike - I really like what you are doing with this tags.xml file - do you have 
any 
idea how to change that to use PHP instead?

Original comment by ccagle8 on 4 Jan 2010 at 1:18

GoogleCodeExporter commented 9 years ago

Original comment by martijn.personal@gmail.com on 2 Jun 2010 at 7:56

GoogleCodeExporter commented 9 years ago
this has been out for a while, closing

Original comment by ccagle8 on 22 Oct 2010 at 2:49