How deep the changes in the API should be?

14.8% 18
13.9% 17
13.9% 17
57.4% 70

122 Дата 20.04.2009 03:09

Форумы / Cotonti / Core Labs / Archive / Опрос: Plugin API changes

<<<123>>>

How far can we go?

Orkan
#16 22.04.2009 05:03
Why I have to be always in opposite? ROTFL

Anyway, I just wonder how you'll gonna implement event registering and broadcasting system without OOP?
Do you have any rough ideas to share at this stage?

I like your "collected suggestions" very much. The 8. SQL query hooks could be done in arrays, I have similar idea already implemented in one of my private projects.
What I would like to add here is the cache system for plugin hooks. I think its possible to join all php files attached to a hook into one file loaded by system instead of include() all the hooked files separately.

Kort:
There are just 37 plugs in the downloads/plugins. Why worry? Brand new.
dont forget about hundreds of private plugins

I will vote for Minor update because of BC.
Brand new or Major upgrade sounds to me like completely new CMS with some functions attached from old Seditio framework ;-)
Perl - the only language that looks the same before and after RSA encryption.
esclkm
#17 22.04.2009 05:16
I think that to remake private plugins easy and fast.
littledev.ru - мой маленький зарождающийся блог о котонти.
снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты
GHengeveld
#18 22.04.2009 05:54
At first I thought you were talking about an API to allow communication between Cotonti and other websites (facebook etc.), but then I read your post saying it isn't about that. I was disappointed to read this, because I would really like to see such functionality, but when I continued reading I found out it wasn't so bad, because the API you're talking about is also something I'd love to see.

I voted Brand new, because I feel there's a lot that can be done to improve the current system, but it's better to start over to prevent clogging the code. Also I think there are improvements that will need an entirely different base to work with. Even though the current hooks system is quite conveniënt and works well for most applications, implementing an entirely new system could make things much easier for us.

I think the new system should be mostly about keeping things easy and simple, so developing a plugin will be easier. The code required to 'install' a plugin and hook it up should be kept to a minimum and should also be well documented. I'm not so much into the technical details of implementing a system like this, but I've seen some welcome ideas in previous posts that I would like to see implemented.
Trustmaster
#19 22.04.2009 12:26
Thanks for sharing your thoughts guys. I agree on most points mentioned above. Here I comment those need commenting.

urlkiller:
i think a more developer friendly sql install should considerd as well as maybe upload packed plugins that get unpacked by the system. would make it far more manageble for the users after.
# yeah, upload a rared archive and the system installs. no ftp crap anymore.

# update function O_o cool would be if you had an external api connection where a file is checked if the installed version is still up to date. if the server is allowed he downloads the new file from server, if he's not allowed he simple announces that a new version is available. this would be very very helpfull in support and bugfixing because everyone would have the latest version. of course this would be a optional feature for very huge plugins. (iam talking here about how hard it was to keep track on every single usergal release.)
Live update isn't very hard implementing. The only reason that makes me feel skeptic about it is security. For this you need to make files writable for PHP. It drops security level by nearly 30%, considering how many hacks were done using TPL Editor plugin and such.

urlkiller:
# while working a lot with ajax its bad that always the whole page gets loaded. would it be possible to have special plugin functions for a second db conection for ajax content? or more like a build in ajax query on the db. where you can execute, edit, add entries?
Take a look at AJAX parts in plugins and a markitup example.

urlkiller:
# google apis java librarys!! can be defined in config and get's properly installed in <head>
i know jquery is there for me, but sometimes the jquery misses some of the kick other libs have...
No need to enable support for every single JS library available on the net. You can switch jQuery off in Admin. We should also implement a compatibility mode option.

Orkan:
Anyway, I just wonder how you'll gonna implement event registering and broadcasting system without OOP?
Do you have any rough ideas to share at this stage?
Don't forget, OOP has procedural code inside. And event handling is done with callbacks.

Orkan:
I like your "collected suggestions" very much. The 8. SQL query hooks could be done in arrays, I have similar idea already implemented in one of my private projects.
Could you post your snippet in pastebin?

Once more, I agree on most of the other points. And our aim is to make plugin development as easy, flexible and clear as possible.

As for interconnection APIs via SOAP, XML-RPC, etc... First we make our internal API, then it will be easier to export some of it to the outer world.
May the Source be with you!
Kilandor
#20 24.04.2009 01:44
Oh yes a new feature would be nice, to install hooks inside of plugins, or un-install (useful for even developing, and you add something new) As well as you could uninstall hooks as well like that.
(Similar to pause/unpause but for installing)

Truthfully compared to many other systems I think our plugins are very easy to develop.

Its just straightforward php, I've seen plugins for wordpress and stuff having to convert them, and the code is a pain in the ass to convert.

Any of our plugins if someone wanted could relativity easy to any system, or just use it standalone.
Отредактировано: Kilandor (24.04.2009 02:51, 15 лет назад)
Orkan
#21 24.04.2009 04:27
8. SQL query hooks.
There are some important queries that a plugin developer would like to modify before they get executed. For example, if you want to affect forum posts order and join it with another table.


Here is my very simple implementation of this idea: http://www.cotonti.com/pastebin/31
I made it for one specific project, where the "query" is passed to several functions modifying it, before it gets executed.
Of course, there is much room for improvement,
Could be done with something more sophisticated, like php class with methods: addWhere(), addJoin(), addOrderBy() etc...
Perl - the only language that looks the same before and after RSA encryption.
Kilandor
#22 24.04.2009 04:47
I think hooking queries could become a bad idea, where say a plugin is expecting something, yet another plugin as changed it.

Not to mention wouldn't this cause alot of overhead, since lets say an average page, has 20 queries?
Trustmaster
#23 24.04.2009 20:18
Query hooks are not for every query, they are for special queries only (say, like 2-3 hookable queries per module). But you're right plugin interoperability could be a problem. A possible solution is a query builder (as requested by urlkiller too). However, this will be low priority.
May the Source be with you!
urlkiller
#24 25.04.2009 00:47
my thoughts regarding the query builder was to let unexpirenced programmers do their own plugins with db support.

its because most low-level plugins (sorry for that) don't have access to the db due to its more to learn for the new developer... so they just let this part out and find some other and not so well working ways to emulate a db, flatfiles etc...

the query thing was just a quick idea where i was thinking would attract a lot more ppl to do their own plugins.

but as i tried to say: make this last. first priority should be the redesign and interoperabillity of cot plugins system itself.

btw. i voted brand new!
but i have to admit i will be crying to the good ol stable system goodbye!
and we should think about that making it as BC as possible to the old system.
or developing a new plugin that has the possibilty to do so...
URL shortener: <a href="http://bbm.li/!7AD5C7">http://bbm.li/!7AD5C7</a>
GHengeveld
#25 26.04.2009 04:36
Just something I came up with.. wouldn't it be nice to have Cotonti automatically run the sql file (if included) when a plugin is installed through the adminpanel. Perhaps with a seperate authentication step so the user knows his database is being modified by the plugin. This would save the hassle of having to use phpMyAdmin to install a plugin.
Actually I feel this should also be implemented for installing Cotonti itself (using a dedicated install script).
TwistedGA
#26 26.04.2009 14:11
I hope this isnt as complicated as it sounds in here. I think I'll be hanging onto each and evry release of cotonti until things get too complicated for me to learn by looking at current code and applying it to the database in my head. The way things are now, is VERY easy to understand.
[color=#CC0000]Lazymod[/color] [color=#000000]Studios[/color]
Trustmaster
#27 26.04.2009 23:21
# Koradhil : Just something I came up with.. wouldn't it be nice to have Cotonti automatically run the sql file (if included) when a plugin is installed through the adminpanel. Perhaps with a seperate authentication step so the user knows his database is being modified by the plugin. This would save the hassle of having to use phpMyAdmin to install a plugin.
Actually I feel this should also be implemented for installing Cotonti itself (using a dedicated install script).
It was implemented a while ago (starting with Sed v125) and is know as install/uninstall scripts. For example see modlist, markitup, attach and some other plugins.
May the Source be with you!
GHengeveld
#28 27.04.2009 04:23
Nice, didn't know this existed. I should implement this in my events/calendar plugin.
urlkiller
#29 03.05.2009 08:07
@Koradhil
isnt there some sort of SQL= (never seen anything here) in the setup file?
i think this is maybe the rest that remained... never seen it used, yet.

would like to have a
SQL=mediaBay.sql
to describe a file that should get exe when hitting install!
edit: to descibe one if no mediaBay.sql exists in sql folder...


@TwistedGA
yeah, in fact he's right. its a rough easy system with the plugins.
if iam remembering right there where a time when we had plugins and extendet plugins, right?
isnt there any possibility to maybe have 2 plugin api's ? like one for advanced plugins using a shitload of code and the normal ones (the sed style ones)?
URL shortener: <a href="http://bbm.li/!7AD5C7">http://bbm.li/!7AD5C7</a>
Elgan
#30 03.05.2009 08:47
i still didnt vote.

however for now. SKimming through, All i see is for an update.

new functions etc. Nothing really drastic or inspiring. just sed_ functions. WHich can be added and used to enhaunce plugins. Then make them more powerful. I find the trouble, have done in the past with not being abole to hook where i need to.

I never used 125, but since cotonti and the install,uninstall thing, Ive finally been able to create some install scripts. Don't forget you can clear plugin body to get yourself a fresh page. Load tpls etc still if need be. I think its safer to not just load an SQL file. Now we have part install. We can do that from there if we wish. I give the user an options.

I also find myself recreating admin panels within the plugin. Something should be done about this.
We should have more access to groups, and auth systems. ive recreated groups in my admin panel ice created. With auth systems that are editable for the plugin. Now thats fair enough. ironicly the groups etc and admin panel is probably neater in my plugin than all spread around cotonti.

but what im trying to say is. In order to create the groups, and the rights system, i just borrowed code from cotonti. However i copy/pasting and slightly editing functions that are only found within admin pages of sed/cotinti and we have no access to as a developer. for example the rights parse line. Ive copied and used in my functions.php. I call it from categories and from groups to just parse the rights pulled from the rights table.

<<<123>>>