cotonti.com : Core functions pluggable

Brock

Thu, 18 Гру 2008 07:46:16 -0000

It's a lot more unneeded code and extra files to include, which certainly can't speed it up. If you're including 50 files rather than 30, don't you think the process would be slower?

esclkm

Thu, 18 Гру 2008 03:53:43 -0000

but why it will be slow? may be wright them in config.php if you mean that it need sql?

Trustmaster

Thu, 18 Гру 2008 03:48:53 -0000

The problem about pluggable functions and extra files which you have described is that it slows everything down. That's why we try to avoid pluggable functions by providing good ones out of the box.

Hmm, is the pagination thing already in Trac? My vbulletin-style would do, but it needs figuring out and fixing some weird bug, or probably using some third-party code.

Lombi

Thu, 18 Гру 2008 03:23:37 -0000

# esclkm : and i think that in new CMS pagination method must be replaced from sedplus plugin

Yeah, either that one or the one that Trustmaster did (vbulletin pagination), this one is horrible.

esclkm

Thu, 18 Гру 2008 00:31:34 -0000

also I think today about pluggable functions/
and I think that rating, comments, parser, pagination must be pluggable
but I think that they must be not look like plugins or replaceble files - they must be something between them.
For example:
folder "functions" in default there are files:
parser.default.php
pagination.default.php
comments.default.php
ratings.default.php etc.

user download and insert in this folder new parser "parser.new.php". And then in admin area he choose parser.

So in this way:
1. this functions are not plugins
2. standart functions we don't need to replace they are only not in functions.php
3. easy to install. easy to choose
4. if user update CMS, custom functions will be not replaced by standart files

what do you think about this?
and i think that in new CMS pagination method must be replaced from sedplus plugin

Trustmaster

Пт, 22 Сер 2008 09:59:29 -0000

They want custom third-party parsers like xBB.

Orkan

Пт, 22 Сер 2008 07:19:59 -0000

yah, I see...
but the question is what they really want? a custom parser or ability to add custom bbcodes?
I would like to hear some arguments here

Trustmaster

Пт, 22 Сер 2008 06:11:19 -0000

Some people REALLY want to, so why not give them a huge piece of happiness? :satisfied

Orkan

Thu, 21 Сер 2008 22:07:35 -0000

as long as we provide a mechanism for adding new bbcodes without replacing standard parser - Im all for it!

Im not sure why you would replace the internal parser?

Trustmaster

Thu, 21 Сер 2008 18:20:14 -0000

Got an idea about third-party parsers. There will be a default one which works from functions.php as usually. And for those, who want to use a third-party parser, there will be a configuration option to switch pluggable parser on, which will be just another include file rather than a hooked plugin. So the overhead is just one "if" for most users and one "include" for "plugin" users.

Kilandor

Сб, 16 Сер 2008 13:40:24 -0000

Yea, we can do it.

I didn't say what I meant though clearly, I meant say, if your testing changes to BBcode, not always new bbcode. But overall I think we can do it so it can be config and on demand re-parsing.

Trustmaster

Сб, 16 Сер 2008 12:51:45 -0000

Kilandor:
*trying to test new bbcode, means re-parsing each time

Not really. Old messages cannot contain this new bbcode, so you don't need to reparse them. New bbcodes automatically apply to new messages and that is not a problem.

Kilandor:
Alt Solution, make a option to enable, pre-parsed message storing.
I think the only true option would be to clear the stored messages, and only have them re-parsed when they are loaded, but you could have an option as well to re-parse all.

Sounds good. Really worth implementing.

Kilandor

Сб, 16 Сер 2008 09:56:37 -0000

To saving pre-parsed, and source text here is what I think

Pro
*Quicker Execution
*No need to parse bbcode every single page load.

Cons
*Making changes, to bbcode require every single page/post to be reparsed - this could create major issues on sites with large date - solution could be to only reparse it when that page/post is loaded
*trying to test new bbcode, means re-parsing each time

Alt Solution, make a option to enable, pre-parsed message storing.

I think the only true option would be to clear the stored messages, and only have them re-parsed when they are loaded, but you could have an option as well to re-parse all.

Trustmaster

Сб, 16 Сер 2008 05:48:11 -0000

By the way, another thing related to parsers and performance is on-demand parsing rather than on display. This way you have 2 fields for each text message: one containing source and the second already rendered for display. So parsing is done only when you add/modify messages or click "reparse all" button in Admin panel. It requires a bit more space for DB, but you don't need any pasing per each request anymore.

Pros/cons?

Trustmaster

Сб, 16 Сер 2008 05:39:14 -0000

The parser situation is quite clear now.

What about the rest pluggable functions Tefra mentioned?

Orkan

Сб, 16 Сер 2008 05:27:57 -0000

"out of the box" means extra disc operations - thats all :wink

I still think this is too much essential feature to have it out of the box.
It'll present in all installations and we will use it a lot in the core.
We should have a control over it and provide an API to extend it - but not to have it pluggable - its too much waste of resources, IMO

Trustmaster

Пт, 15 Сер 2008 19:51:31 -0000

Isn't it a right place to do it?

As far as I see it would be better to combine the efforts to have a powerful bbcode parser out of the box with bbcode editor and API to add/remove bbcodes in plugins, with all PCRE and "remove extra
" patches applied, and completely reworked HTML parsing mode.

Orkan

Пт, 15 Сер 2008 16:40:52 -0000

The parser() problem is a good subiect for separate discussion, where we could list all possible combinations of use and then.. find the most appropriate solution :)

Kilandor

Пт, 15 Сер 2008 16:27:32 -0000

Actually as far as bbcode is concerned, I propose my plugin/sql system, be used. BBcode can be easily added to a sql db which is then accessable by any/every plugin.

As the parser functions pull from that data, and its cached. Mysql usage like this is very very minimal, as it uses a cache.

I don't see any other options unless you created a painful file creating structure to add and store it all in a php file, that had api access, which would be a bit more difficult, not to mention more chances for problems

And maybe some similar creation can be done for the others.

Trustmaster

Пт, 15 Сер 2008 15:14:00 -0000

I see the point. Obviously there should be a lower level API functions like sed_bbcode_add() and sed_bbcode_remove(). But I was talking of parser logic, not data. For example, a parser that will validate WYSIWYG HTML or add Wiki syntax support.

But, of course, if we could put all the parsers in one powerful parser, I would be all for it. The problem I encountered with parser_v2 is that those 2 arrays for str_replace() and preg_replace() (yeah, forget eregi, it's much slower) are not enough and for some sophisticated parsing you need preg_replace_callback() and custom functions. At that, some parser functions conflict with each other (e.g. nl2br).

I can't say I'm all for many parser mods, but are you sure it is possible to have superior one?

Orkan

Пт, 15 Сер 2008 13:33:29 -0000

Well, I have completely different idea about the parser in SED.

Lets say you have installed a new gallery plugin which adds new bbcode [photoid=123]
Then, you have yet another plugin ie. for flash movies, with new bbcode [movie]...[/movie]

How this will work with modules? You cant replace one parser with another b/c that way you lose the other one.

I would like to see one, internal Parser() function which will operate on two arrays.
PS. These 2 arrays are now "closed" in sed_bbcode() - one for str_replace() and one for eregi_replace()

Both arrays should be stored in DB and therefore be accessible to any plugin.
Each time you install new plugin, it can add new bbcodes to DB.

What I mean is that we need only one powerful Parser() function with its basic functionality.
With modules we can only destroy Seditio's clarity and code integrity.

I would suggest - instead of modules - creating flexible functions that plugins can use with their own data. There is no point in copying Sed's functions to modules, IMO :)

Trustmaster

Пт, 15 Сер 2008 08:20:50 -0000

Previous threads:
http://www.neocrome.net/plug.php?e=tracker&m=bview&pr=1&id=404
http://www.neocrome.net/forums.php?m=posts&p=123836#123836

Well, I think we don't really need them as plugins, because you are not likely to install more than 1 parsers at once (otherwise they will conflict).

What I would suggest right now is to have some of core functions you would like to replace grouped in "modules" like:
system/mods/parser.inc.php
system/mods/pagination.inc.php

So, once you need another parser, you just download third-party parser.inc.php and replace the default one. Yes, that will add a few more require's in common.php, but that's still faster than having them as plugins. And I made includes work slightly faster, see Ticket #39 on Trac.

Alternatively, could pick up all includes in system/mods folder, but that will be more disk operations.