splitPageResults

[quentinjs]

This is a very cool class, atleast in concept, but it has a serious problem when you need a group by clause.

I am doing a

select product_id, sum(xxxxx) from product join table_with_many_product references group by product_id

result : 500

not syntacticly correct, but you get the idea. The parser does a great job of building up a "count(*) version.

select count(*) from product join table_with_many_product references

result 60,000

so I am going to be updating this class tomorrow to allow more flexibility. I can think of a couple ways of doing this.
1. Let the caller specify the entire SQL for counting.
2. Allow the caller to specify a key field, or fields.

Or both.
in 2.

select count( distinct product_id) from product join table_with_many_product references

would work fine for me, but maybe not for everyone. Also since I'm opening this scary can of worms , what external concerns should I be aware of, or is there anything else that should be done with this class while I am at it?

..... and to think all I wanted to do was create a report of products viewed... now I have ued the notification system, created a zen report class, 15 reports for it, and am about to change core code as well... who'd have known!

and earlier today I thought, just a little more testing and I can release it to the ZC community.

[wilt]

Hi,

I guess u are looking at the admin split page result class. You might want to take a look at the version in catalog as this has better support for distincts/group by's and includes the option of using a key field.

Work has been done in development branch to port this across to use in admin instead of the current admin class.

[quentinjs]

Nice. I'll take a look at that, as it sounds like what I need! And savs me from a couple days of work!

Now for the questions....
1. You mentioned the admin one being redone... time frame for this?
2. I take it I'd have to specifically map to the split page file in the catalog section as an interm solution to making this work.

Time for life n decorating.

[wilt]

As far as using the catalog verion in admin, its not too big a problem for a one off page. However thats complicated by the fact that both versions use the same class name. You could just copy the catalog one across to admin, change the class name then require it on a one off basis for the new page you are building.

However completely porting to admin is a little harder as each class has a completely different set of methods and api.

[quentinjs]

That actually without even looking at it, the fact it was rebuilt instead of patched in is a good thing. I'll figure out a way to temporarily patch in the cataglog version until some subsequent admin update.

[quentinjs]

I finally found a late night to play with this again, and incoprporate the new SplitPageResults class into my reporting class.

Problem:
1. In the class there is a line

        $display_links_string .= '&nbsp;<a href="' . zen_href_link($_GET['main_page'], $parameters . $this->page_name . '=' . $jump_to_page, $request_type) . '" title=" ' . sprintf(PREVNEXT_TITLE_PAGE_NO, $jump_to_page) . ' ">' . $jump_to_page . '</a>&nbsp;';

My concern is that the "main_page" is hard coded into this. The other problem I'm having is that I don't have a "main_page" in the $_GET to use. On the first call to this function its via a set of query parameters that know nothing about the "main_page".

Problem #2 is that if we are using $_GET it shouldn't assume that the value exists. At the same time, it should also check the $_POST as well as it could be in the form. The class needs to be robust and handle as many possible cases as possible. Its still very hard coded into the current "ZenCart" way of life, which works but doesn't make ZenCart changeable, we need to make sure all new code added is dynamic and doesn't rely on assumptions of the current model, as otherwise the we can't easily migrate it in the future.

As an important note, there is code in the Admin that the original splitpage used that made it impossible to place the "zenReport" stuff all in a subdirectory, it was to buried. And worst of all there was no reason for this HARD CODED behavior to exist. It makes it difficult to extend ZenCart and you spend more time struggling with the foundation classes then extending it. So this is the reason I mention NOT making assumptions that a "get" value will exist, when there is a more class oriented way of doing things.

So back to my problem, perhaps I'm using the class wrong, but I am thinking that the class requires 2 changes

1. a property should be added to specify the "key name" to be used or better would be to have it set the "main_page" name in the class as a property. I don't think its necessary to have it as part of the $_GET at all. A migration hack would be to check for the param, and if its null, then look at the $_GET AND $_POST for the 'main_page'

I'll look at this again tomorrow... but if anyone has a mini example it working with the "display_links" method being used would be great.

Thanks in advance!

[DrByte]

Since you are using this class for the Admin area, the $_GET['main_page'] reference is, as you mention, completely irrelevant, as the Admin doesn't use the main_page parameter in its URLs at the present time.

You'll notice that the default behaviour for this in the current admin version of this class is to use basename($PHP_SELF) instead.




As an aside, in the catalog/storefront side of things, $current_page_base is the variable available to reference for the currently-displayed page. Inside a method it'll have to be declared as a global in order to use it.

As to the coding recommendations, you are correct that there are some things to tidy in that file. Some have been done in the v1.4 code under development. More will follow in due course.

[quentinjs]

Thanks DrByte,

I just know from other posts that there is a desire for a common base of code for both the admin. and catalog sides, so its important. BTW I hated that BASENAME as it stripped off pathing and made a mess of things, so this class is progress...