[geeklog-devel] Geeklog Pagnation

[Wim Niemans]

There is no need to patch any core, and I did not. 
Except some bugs of which I know that are contained in the next release.
Though I duplicated ADMIN_list and ADMIN_menu because they interfere with sql navigation.

And I don’t think it is a lot of work, unless testing is meant.
In order to give this a go, there should be a correct plugin repository and maybe a generic procedure to get a plugin supported.

Wim

On 30 Mar 2014, at 17:03, Tom <websitemaster at cogeco.net> wrote:

> 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
> 
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://eight.pairlist.net/mailman/listinfo/geeklog-devel
>