How far can we go?
Orkan |
|
---|---|
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: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 |
|
---|---|
I think that to remake private plugins easy and fast.
littledev.ru - мой маленький зарождающийся блог о котонти.
снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты |
GHengeveld |
|
---|---|
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 |
|
---|---|
Thanks for sharing your thoughts guys. I agree on most points mentioned above. Here I comment those need commenting.
urlkiller: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:Take a look at AJAX parts in plugins and a markitup example. urlkiller: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:Don't forget, OOP has procedural code inside. And event handling is done with callbacks. Orkan: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 |
|
---|---|
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. |
|
This post was edited by Kilandor (2009-04-24 02:51, 15 years ago) |
Orkan |
|
---|---|
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 |
|
---|---|
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 |
|
---|---|
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 |
|
---|---|
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 |
|
---|---|
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 |
|
---|---|
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 |
|
---|---|
# 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.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 |
|
---|---|
Nice, didn't know this existed. I should implement this in my events/calendar plugin.
|
urlkiller |
|
---|---|
@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 |
|
---|---|
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. |