Please login or register.

Login with username, password and session length
Advanced search  

News:

Latest sNews - sNews 1.7 - with its own forums - for discussion and user mods.

Pages: 1 [2]

Author Topic: Plugin System  (Read 11111 times)

Keyrocks

  • Doug
  • ULTIMATE member
  • ******
  • Karma: 449
  • Posts: 6019
  • Semantically Challenged
    • snews.ca
Re: Plugin System
« Reply #15 on: September 13, 2009, 08:05:02 PM »

How you 're-write' or modify the sNews engine all depends on what you want the sNews engine to do for you.

In my case, I developed a module inclusion system for sNews 1.6 and it works OK for me so far.
I suppose it could be taken to another level or two in terms of automation but I haven't taken it there yet.

It came to me that - no matter what functionality I wanted to add to sNews 1.6 - the same inclusions had to be made in the same group of functions in the snews.php file. This was the case both for functions that display content to viewers and functions that provide for administrative work.

My approach was to use module folders that contained same-named files with scripts to be included in the snews.php functions... when detected by condition-checks that check to see if the module is enabled and, if it is, include its script files.

With the help of a couple other sNews members, my modifications included:
      1.  detect-include scripts in each of the snews.php functions where inclusions are required (to run a module);
      2.  all modules are unique-named folders, with same-named files containing the functions being called when included;
      3.  an admin panel where module folder-names are added, activated, disabled, or deleted.

All of these modifications are additions to existing sNews 1.6 snews.php functions, and none required re-writing of any default functions.
Logged
Do it now... later may not come.
-------------------------------------------------------------------------------------------------
sNews 1.6 MESU | sNews 1.6 MEMU

sNews3M

  • Newbie
  • *
  • Karma: 3
  • Posts: 21
  • nothing can be impeccable in this imperfect world
    • Free Multiuser Multilingual Content Management System sNews 3M CMS
Re: Plugin System
« Reply #16 on: September 13, 2009, 08:57:42 PM »

Most software and CMSs have an API for developers to add functionality.  This CMS should be no different for add on/ plugin whatever functionality.  If it is truely a developer's tool, then it should be defined as such for a developer to work with - refactored code and made to scale.

Excellent, but I see that you don't want go by a simple way ;D
I'm want ask a simple question and expect a simple answer
Which API for plugins connecting is in sNewsCMS now?

this idea based on replace source code by addons system.
If I am understanding you correctly, it sounds like Luka's mod my sNews idea here: http://snewscms.com/forum/index.php?topic=5995.0
--sarcasm--  This idea took off very well because of the fact that you have mods that replace mods and you have mod packages and the like.  --/sarcasm--
I think that it's a great idea for sNewsCMS, but not quite complete and not brought to usefull state
And I thought about this same as Luka 8) Thanks for link
« Last Edit: September 13, 2009, 09:26:29 PM by sNews3M »
Logged
Free Multiuser Multilingual
Content Management System
sNews 3M CMS
sNews MM 1.6.3
please forgive my terrible english :)

nukpana

  • Hero Member
  • *****
  • Karma: 71
  • Posts: 663
Re: Plugin System
« Reply #17 on: September 13, 2009, 09:42:04 PM »

Excellent, but I see that you don't want go by a simple way ;D

No, for 2.0, it has been stated to be a rewrite.  I am just echoing the main author's words

Quote
I'm want ask a simple question and expect a simple answer
Which API for plugins connecting is in sNewsCMS now?
Simple Answer - None.

As you can see by the 'mod' section, everything is done by hand - highly inefficient to a developer and not good for each version that comes out - which in turn may change the functionality by version.  Case in point - 1.6 to 1.7.  In addition, with mod packages, no two installations are the same and core files need to be edited.

Quote
How you 're-write' or modify the sNews engine all depends on what you want the sNews engine to do for you.
Doug,
I assumed this talk was for the upcoming versions and code discussions and development.  If I was going to rewrite the engine, then I wouldn't need to use sNews as it's job as being a developers tool is false.

Your modules package is fine, but for further editing/hacking/modding, then core files would have to be edited - unless you implemented "hooks" that would reach into the core functions, but this leads back to my earlier discussions - which to date, is not catching on with the core sNews developers...
Logged

Keyrocks

  • Doug
  • ULTIMATE member
  • ******
  • Karma: 449
  • Posts: 6019
  • Semantically Challenged
    • snews.ca
Re: Plugin System
« Reply #18 on: September 14, 2009, 04:45:01 AM »


Quote
How you 're-write' or modify the sNews engine all depends on what you want the sNews engine to do for you.
Doug,
I assumed this talk was for the upcoming versions and code discussions and development.  If I was going to rewrite the engine, then I wouldn't need to use sNews as it's job as being a developers tool is false.

Your modules package is fine, but for further editing/hacking/modding, then core files would have to be edited - unless you implemented "hooks" that would reach into the core functions, but this leads back to my earlier discussions - which to date, is not catching on with the core sNews developers...

This topic is within the sNews 1.6 Suggestions board so I suppose we can discuss any exploratory project here.
While my exploration of a modular approach is done with 1.6, it can be easily adapted to 1.7 and, perhaps, even be worth considering for future versions. Of course, possible application to a future 2.0 sNews is unknown since we've no idea what 2.0 would look like, as you've noted.

There is no need for additional modding/editing/editing with my modular approach. Instead, each module is created using the same number of same-named files so that the detect/inclusion functions (and scripts added to existing functions) added to snews.php locates and includes them automatically once a module is installed and enabled. The functions and additional scripts in snews.php automatically detect and include files in each module for:
- global variables,
- language variables,
- cat_listSEF function & action-names,
- link generators,
- css stylesheet file-paths,
- index.php files containing all of the module's functions,
- admin files containing all of the module's admin functions (for those that use them),
- admin.case and main.case strings for inclusion in function center's action-switch groups.

So there is no need to go back into the engine functions provided each module is structured according to the same format.

That said, I am not suggesting that anyone else needs to follow or explore my modular approach any further though anyone is free to do so.
I am sure it does have limitations but the fact that it does work fairly well so far encourages me to continue working with it over time.
Logged
Do it now... later may not come.
-------------------------------------------------------------------------------------------------
sNews 1.6 MESU | sNews 1.6 MEMU

Joost

  • Guest
Re: Plugin System
« Reply #19 on: September 14, 2009, 04:52:32 AM »

--sarcasm--  This idea took off very well because of the fact that you have mods that replace mods and you have mod packages and the like.  --/sarcasm--

 It is a diff/grep-for-snews-only utility. It is a large project by itself. While at it, it would be better to develop such utility for php applications in general. However, such utilities do exist.

Now, the keywords in this discussion, are developer and API. To find out how the API should look, we need to define the devloper first:
What is a developer? What are developers developing for? As sNews developer, having a small core to work with is most favourable, I think. As Website developer, having sNews with plugins is most beneficial, I believe. It all depends on where you want to spend you time coding and what you are developing.

He's right. If we don't who the developer is, for whom we are writing an API, we cannot write a decent API.
Some examples of flawed sNews API (yes, functions can be considered being API):

function tags: After all these years, I still don't understand it. Not as a frontend engineer, not as a core developer.
function html_input:  Gives me a headache. Both as a frontend engineer and core developer.
function retrieve: The most misused function in the system. While easy to apply, it is not fool-proof.
Core developers should not use it. For whom is it written anyway?

PHP itself is known for the overkill and redundancy of API/functions.
Where a coder could use:
If ( $a == (int)$a )
PHP provides the following functions:
function is_int
function ctype_digit
function is_numeric ( mentioned nowhere: Returns true on floats as well !!!!. "numeric" is not a type)

Similar:  If ( ! isset($a) ) vs is_null($a)

Problem: All these functions doing (almost) the same thing is confusing. People tend to think these functions are there for a reason!
Side note: The worse API in php, is probably provided by filter

In Javascript, there are many different frameworks, such as: Jquery, Mootools, Prototype.
Each having there own API. I think most of these API have become quite complex.
To get the best out of Jquery, you have to study Jquery (there is a book).
It might be better to study javascript instead.

These examples show, the importance of defining the developer/user of an API. Else, you might end up with an API that's:
1) - hard to understand.
Most API extend the vocabulary of a programming language. If an API, originally existing of  only a few "words" grows, it becomes a language of its own, forcing user to learn that new language.
2) - inflexible.
When developing an API, choices have to be made. A decision can make life easier for a noob, while at the same time, making it harder for anyone else.
3) - a pure waist of resources.
Redundant to mention this: However, if an API fails to do what it is designed for, or if the trade-off tips the balance the wrong direction, it is a bloody waist.
Of course, even for "the ideal" API, there is a trade-off, though an acceptable trade-off.

An example of a fine API:
 I consider index.php (the template) an API as well. From the perspective of a frontend engineer, it is great:
- It is flexible and easy to understand ( I don't remember ever having to consult any help pages ).
However, it is geared towards  frontend engineers! Not php developers, not database developers, not administrators.
And that's my main point: When developing an API, you have to know beforehand, who to put in the spotlight.
With this in mind, lets narrow it down to API for plugin systems (what this thread is all about):
As I understand it, Jason wants a plugin system that does not require any editing of (config) files or code modification. A plugin system geared towards the non-coder. So most likely the trade-off will affect developers who do write code, making the system less flexible to modify.
I have installed systems like cmsMadeSimple for clients. I had to do the configuration as well, as most people get lost with all those form settings. Not to mention the problems I encountered myself with Smarty. So I am quite skeptic about plugin-systems and intuitive API.

The same skepsis I have regarding Luka's proposal, which basically comes down to a one-file, online plugin-system that can be converted to systems such as: a gallery, cms, blog or whatever, by adding a one-file module.

My preference is a system that's somewhere between framework and plugin-system (note: a default installation should be ready to go).
The API should be geared towards frontend engineers: Those guys and gals have no problem with adding an include, so no need to fool around with settings forms and bloated automation.
Being a fan of the UNIX Philosophy "Make each program do one thing well" (many older perl programs use the same approach), programs such as: archive, sitemap, contact, sitemap.xml, filemanager or guestbook will all be standalone applications.
Again, no problem for frontend engineers. If someone prefers sitemap "b" over sitemap "a", he/she can upload that particular file.
Menus will be located in a separate file, making it easier to replace for a different type.
Same goes for wysiwyg-editors. They should be easy to replace/add, without having to worry about functionality such as php execution in text (I would never allow a (human) editor, to use php in the first place, as I classify it being a webmaster's task: The webmaster should be the one with control over the webspace, no-one else).

Of course, if some genius invents a system that suits everyone, I am converted.

Logged

nukpana

  • Hero Member
  • *****
  • Karma: 71
  • Posts: 663
Re: Plugin System
« Reply #20 on: September 14, 2009, 06:51:49 AM »

Quote
As I understand it, Jason wants a plugin system that does not require any editing of (config) files or code modification.

And that is a bad thing how?

Quote
A plugin system geared towards the non-coder. So most likely the trade-off will affect developers who do write code, making the system less flexible to modify.
I am highly doubtful there.  Where are you getting this from? 

What part of this is less flexible to modify: http://snewscms.com/forum/index.php?topic=7155.msg61237#msg61237

Quote
The API should be geared towards frontend engineers: Those guys and gals have no problem with adding an include, so no need to fool around with settings forms and bloated automation.

I hope an API would be for the developers too - easy and simple so "developers with beginner-to-advanced PHP skills" can write plugins as well.  Also the end users, they have no problem going to a site and downloading a plugin to have it work with the system.  Those users may not know how to include a file or two.

Doesn't sNews have settings forms and the like?  I am pretty sure if you wanted a archive in the format you note of, you may have settings to set specific to the plugin.  Not sure how different that is...

Bloated automation?  Not sure where that came from - I used the same system but didn't note that.

Quote
Being a fan of the UNIX Philosophy "Make each program do one thing well" (many older perl programs use the same approach), programs such as: archive, sitemap, contact, sitemap.xml, filemanager or guestbook will all be standalone applications.
Again, no problem for frontend engineers. If someone prefers sitemap "b" over sitemap "a", he/she can upload that particular file.
Right, exactly what I mean too, but going back to the previous example, what about an infoline?  That "can" be included, but how do you link it -  it would have to be a hook somewhere?  If it is hard-coded, like how it is currently, how would you then modify it?  If in the browser, then automation is needed there (that's an API too), if not, then you are back to editing the core files which brings you back to square one.

Quote
Quote from: jackp on April 08, 2008, 04:01:03 AM
What is a developer? What are developers developing for? As sNews developer, having a small core to work with is most favourable, I think. As Website developer, having sNews with plugins is most beneficial, I believe. It all depends on where you want to spend you time coding and what you are developing.

He's right. If we don't who the developer is, for whom we are writing an API, we cannot write a decent API.

I think that is largly the problem, there are two types of "developers" that is being referred to and neither is being noted correctly.  One is the backend developer(php/sql) and the other is the front end developer (html/css/js).   The core devs (or dudes) abstract the core and make it simple, small and legible so anyone can read, then have an API that is easy for anyone to extend. You state the API should be for the front-end developer.  I don't know if that is the answer, but I still say make it for everyone... you will disagree so....

Quote
Of course, if some genius invents a system that suits everyone, I am converted.

I don't think this should be rocket science.  As stated before, most system use a hook system and it is proven (vBulliten and phpBB3 forum software are a few to note).  I posted a simple solution here - 2 functions, one is 2 lines!!

If the future of this system is going with config files and includes, then I think it is a step in the wrong direction. 
Logged

nukpana

  • Hero Member
  • *****
  • Karma: 71
  • Posts: 663
Re: Plugin System
« Reply #21 on: September 14, 2009, 07:01:44 AM »

Quote
Of course, possible application to a future 2.0 sNews is unknown since we've no idea what 2.0 would look like, as you've noted.

I noted nothing in that regards. Luka noted what 2.0 would/should look like 6 months ago. Nothing has been noted from Luka or the core devs publicly since, and per this discussion, nothing seemed to progressed any further.
Logged

Joost

  • Guest
Re: Plugin System
« Reply #22 on: September 14, 2009, 09:25:28 AM »

Quote
As I understand it, Jason wants a plugin system that does not require any editing of (config) files or code modification.

And that is a bad thing how?

Quote
A plugin system geared towards the non-coder. So most likely the trade-off will affect developers who do write code, making the system less flexible to modify.
I am highly doubtful there.  Where are you getting this from? 

What part of this is less flexible to modify: http://snewscms.com/forum/index.php?topic=7155.msg61237#msg61237

- I never said it is a bad thing. I referred to something you said somewhere else, in order to clarify the context in which I reply. Someone else might read it and might wanna know what we are talking about.

- When an API is forced upon a developer, loss of flexibility is inevitable, because the developer who created the API, has to decide which choices/settings the API provides. That can never be the same number options as the language it replaces (html, css, php etc.) and remain a simple interface at the same time (simple is a design goal, ain't it?).
So obviously, there will be loss of flexibility.

In my previous post, I tried to explain what my concerns are. I've explained my way of reasoning, weighing pros and cons. My conclusion is: I won't go for a plugin system the way you've described and I described my preference (and where my project is going).
So if a frontend engineer would like to modify the infoline in my system, he'd be looking at something like:
echo "<p class="info">$time $info</p>";,
which is much more clear than the API sNews provides:

Code: [Select]
$tags = array(
'infoline' => '<p class="date">,readmore,comments,date,edit,</p>',
'comments' => '<p class="meta">,name, '.l('on').' ,date,edit,</p>,<p class="comment">,comment,</p>'
);
and
Code: [Select]
function tags($tag) {
global $tags;
return $tags[$tag];
}

and

Code: [Select]
if (!empty($currentPage)) {
if ($infoline == true) {
$tag = explode(',', tags('infoline'));
foreach ($tag as $tag) {
switch (true) {
case ($tag == 'date'):
echo $a_date_format;
break;
case ($tag == 'readmore' && strlen($r['text']) > $shorten):
echo $link.$uri.'/'.$r['asef'].'/">'.l('read_more').'</a> ';
break;
case ($tag == 'comments' && ($commentable == 'YES' || $commentable == 'FREEZ')):
echo $link.$uri.'/'.$r['asef'].'/#'.l('comment').'1">
'.l('comments').' ('.$comments_num.')</a> ';
break;
case ($tag == 'edit' && _ADMIN):
echo ' '.$edit_link;
break;
case ($tag != 'readmore' && $tag != 'comments' && $tag != 'edit'):
echo $tag;
break;
}
}

(I still don't know what I am looking at  ??? )

I don't think my approach will bring me back to square one:
- The enduser will still be able to install a cms out of the box.
- A developer will have the freedom to do whatever he's capable at.
- I am not as much in need of a plugin system as you seem to be. So I am not taking any trade-off as lightly as you.
Therefore that plugin system and its API have to be quite good before I go down that road.
Logged

nukpana

  • Hero Member
  • *****
  • Karma: 71
  • Posts: 663
Re: Plugin System
« Reply #23 on: September 14, 2009, 12:34:58 PM »

I totally understand your concerns and I agree with them.  My reasoning is hopefully beneficial to the community, not just for myself.  That being said, I will go my own route and build a new system outside of this community.
Logged

Keyrocks

  • Doug
  • ULTIMATE member
  • ******
  • Karma: 449
  • Posts: 6019
  • Semantically Challenged
    • snews.ca
Re: Plugin System
« Reply #24 on: September 14, 2009, 05:34:25 PM »

I totally understand your concerns and I agree with them.  My reasoning is hopefully beneficial to the community, not just for myself.  That being said, I will go my own route and build a new system outside of this community.

@ Jason (I assume we're conversing with Jason Parks, correct me if I am wrong)... you're reasoning may be beneficial to the community. Your heart is in the right place. I think you do need to build the system you envision. You've already posted a lot of code (in other locations) based on your vision. The difficulty I have is not with what you envision or propose, but that I do not understand where you are going with it.

So, if you build a complete system as you envision... to the point where it is fully functional and working with all its parts in place... then members (like Joost and I) would have something to install, work with and learn from. We'd all appreciate you sharing it when it gets to that stage. If you must do it "outside this community", that's fine too but it would be nice to have you share it here.  :)
Logged
Do it now... later may not come.
-------------------------------------------------------------------------------------------------
sNews 1.6 MESU | sNews 1.6 MEMU

Joost

  • Guest
Re: Plugin System
« Reply #25 on: September 15, 2009, 01:01:49 AM »

That being said, I will go my own route and build a new system outside of this community.

Yes, you should. There will always be a spin-off, something of interest.
sNlite encouraged me, to make my system sqlite compliant (queries).
Besides, when working on a personal project, you can implement a vision of your own, no need to bargain.
« Last Edit: September 15, 2009, 01:04:01 AM by Joost »
Logged
Pages: 1 [2]