Quote:
I have the understanding that it is the other way around. They are still compatible with 2.0.18, but 2.3.x isn't any longer. So, XOOPS is moving away from itself.
Ok, we can look at this in two ways, we can first say, yes XOOPS is moving away from its self. It’s the normal progression in development and especially when developed on a platform like PHP. As PHP progresses, we then discover new ways or added functionality that we can use in our scripts.
The fact is this, we cannot stay still for to long, and we have already seen the problems this has caused with XOOPS Modules not keeping up with the core development of PHP.
Xoops has to move away from itself in order to survive and keep up with every other CMS and that requires that now and then we have to break a few eggs.
Quote:
No, and I don't either. When I am talking about compatibility is that when a module runs perfect with 2.0.18, it should still run with 2.3.3.
For newer modules which use the extended features of 2.3.3, it is normal that they will not and don't have to run with 2.0.18.
If one follows the API of XOOPS this should not be a problem. New features has to be added with respect for the old. So, we get an evolution.
We don't want a revolution, where things are trown overboard or are changed for the changement.
I agree to some point. You have to look at it this way, how long do you actually keep compatibility with older systems before the API becomes full of redundant code and ends up being Bloat ware? The answer is that you can only realistically keep some backward compatibility over a certain period of time and after that the API needs to trim itself of redundant code.
The truth of the matter is this; we wouldn’t be having this discussion if the modules followed the exact same development path as the core. This has not been the case. Module development has fallen so far back, so now more or less all XOOPS modules will only run on PHP4 and XOOPS version 2.18 and thus probably keeps people from moving to XOOPS 2.3 or even possibly upgrading to PHP 5.
So now that we are bringing XOOPS modules into line with the core, people will either turn one or two ways, ‘You have broken my modules and Xoops’ Or Wonderful I can now update my PHP and Xoops. The truth of the matter is that we will be damned if we don’t and possibly damned if we do. Right now, you can damn me all you like for doing ;)
Quote:
Also I notice a method like get_objs or something that performs two queries, one to get a count of all available objects and other to get just a limited number of objects. I think it would be better to use just one query, count the resulting array, and then unset the not need objects according to the criteria.
In order to use the Navigation system within XOOPS, I first need to know exactly how many items there’re within the database in order to count how many pages the navigation will split by the number of articles actually displayed.
Ie. If 10 items are displayed per list and there is a total of 100 in the database, the count tells us to split the Navigation in to 10 pages from the previous and next. If I were to do it the way you suggested, then I would only ever have one page of ten items listed.
If you have another method I can use to do this, I would be pleased if you could show me. So far this is the only way of getting the total records and the actual records, and have the page navigation split by the total*actual into a working page navigation.
Quote:
OK, the module is targetted for developers and not for users. I missed that point.
Nope, the modules are targeted for everyone, user, new developers and mature developers, to better understand the working of a XOOPS module. As I said before, these modules are work in progress, and we want to have working versions that show how the XOOPS API works, and the only way to do this is to lead by example.
I hope this answers some of your questions, anyway, off to convert another module.
