Closed GoogleCodeExporter closed 9 years ago
I like this idea. Great idea Martijn
Original comment by ccagle8
on 2 Jan 2010 at 1:28
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
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
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
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:
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
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
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
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
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
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
Original comment by martijn.personal@gmail.com
on 2 Jun 2010 at 7:56
this has been out for a while, closing
Original comment by ccagle8
on 22 Oct 2010 at 2:49
Original issue reported on code.google.com by
martijn.personal@gmail.com
on 2 Jan 2010 at 12:49