[geeklog-devel] Geeklog Pagnation

[Wim Niemans]

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-relnext-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
>