[geeklog-devel] Geeklog Pagnation

[Tom]

As you said the right way to do it would be to use a class (that's a lot of
work :-). You brought up some interesting ideas with your page keyword
example. You mention your glface class. Have you already been modifying the
Geeklog core?

Right now we have 2 ways to generate a page.

The original way using the functions COM_SiteHeader, COM_SiteFooter, etc... 

The current way (as of Geeklog 2.0.0) using COM_createHTMLDocument

If for Geeklog 2.2.0 (or 3.0 or whatever we call it) we introduce a page
class we need to make sure it is backwards compatible with at least
COM_createHTMLDocument. COM_createHTMLDocument could just become a shell
function that accesses the page class directly. 

If this does get worked on we would need to figure a number of things out.
Like you said the SCRIPTS class could get integrated and a lot of the plugin
api stuff could be dropped if the page class can be accessed directly. A lot
of the stuff in lib-common could move to the class as well (as you mentioned
but backwards compatible will be an issue). We may also want to do this in
baby steps to try and keep plugins as compatible as possible.

The layout of the class will have to be thought out carefully so we can make
sure it allows for backwards compatibility and allow us to move forward
easily when we want to add new page features.

Tom
 


-----Original Message-----
From: geeklog-devel-bounces at lists.geeklog.net
[mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Wim Niemans
Sent: March-30-14 6:20 AM
To: Geeklog Development
Subject: Re: [geeklog-devel] Geeklog Pagnation

It's evident and un-avoidable that gl needs to proceed to a html-page class.
That also can be 'hidden' to the plugin or explicitly published.

My example is using a class that can store the information for later use;
all output functions can -additionally- use the class, even
createHtmlDocument can.
I've got a class called pluginFace that extends glFace as the main class
(abstract).
In pluginFace the plugin content is assembled and glFace gathers all content
from it's 'children'.
The trick is defining keywords and attach content to them. A overall
pageLayout variable defines the sequence these keywords will follow (in a
array). This enables the plugin to generate content without knowing how the
page design (or block design) is set up, so the logic has priority and the
flow is much more readable. In other words, it would be very feasible to
generate content in the plugin that shows up in configurable spots of the
page. 
This works marvellous and the keyword 'debug' gathers (optionally) all debug
output.

Example: 
pageLayout=('menu', 'search', 'pagination', 'list', 'pagination');
glPage::addContent('pagination', COM_printPagination(...)); or
glPage::addPagination('navigation', ...); This example shows a clone feature
that allows the pagination to show before AND after the list, without any
extra logic. This example shows also that this can be done with BC.

Say, you have a glPage class (abstract and static) and all output functions
start to store their information in that class, like glPage::setParam(type,
param). The function createHtmlDocument does the same with the information
array. Than the function is using solely the new class, migrating the code
in suitable cases to the class.
So, a choice becomes available to generate content directly (and attach that
content to the class) or just store the params that are used to generate
content (later on), or even do both or use a mixed approach.

Than, adding a method like 'addResources' can obsolete the SCRIPTS class,
since the class will have all information to generate a complete page. Even
the functions for startBlock and endBlock can migrate to the new class. Not
to mention that the class might be standardised to catch ajax calls in a
geeklog way.

In the end, gl will end up with a generic page class, a configurable
pageLayout (independent from themes), tiny, simple, plugable classes for
blocks, addons, style elements and such.

Finally, doing so, documentation will benefit since all responses are within
a single class, which may be extended if desired. lib-common just contains
placeholders. All other system-libs may access the class if needed, which is
nearly impossible in the current architecture. 

I am using a similar approach for exceptions.

Wim


On 30 Mar 2014, at 05:24, Tom <websitemaster at cogeco.net> wrote:

> I need to add pagination to one of my sites:
> 
> http://googlewebmastercentral.blogspot.ca/2011/09/pagination-with-reln
> ext-an
> d-relprev.html
> 
> It allows Google to know what the next and previous pages are with the 
> content and browsers like Firefox will prefetch the next page to allow 
> for faster loading.
> 
> I plan to add this to the next version of Geeklog
> 
> http://project.geeklog.net/tracking/view.php?id=1754
> 
> At first I was think this would be easy to do with only a few small
changes.
> We have all of the information needed in the function 
> COM_printPageNavigation (ie the urls for the previous and next page). 
> We even have a spot in COM_createHTMLDocument that creates a bunch of 
> link elements  (like $relLinks['canonical']).
> 
> The problem is the function createHTMLDocument (and COM_SiteHeader) 
> retrieves it's data either from the parameters passed to it or by 
> running the custom and plugin api. COM_printPageNavigation has the 
> information we need but once the page navigation html is generated the 
> urls are lost. Since COM_createHTMLDocument isn't a class that I can 
> access with in COM_printPageNavigation to store the data to use later 
> when the page is created what suggestions do people have to handle this?
> 
> Tom
> 
> 
> 
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://eight.pairlist.net/mailman/listinfo/geeklog-devel
> 

_______________________________________________
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net
http://eight.pairlist.net/mailman/listinfo/geeklog-devel