| Trustmaster |
|
|---|---|
|
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. May the Source be with you!
|
| Orkan |
|
|---|---|
|
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 :) Perl - the only language that looks the same before and after RSA encryption.
|
| Trustmaster |
|
|---|---|
|
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? May the Source be with you!
|
| Kilandor |
|
|---|---|
|
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. |
| Orkan |
|
|---|---|
|
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 :)
Perl - the only language that looks the same before and after RSA encryption.
|
| Trustmaster |
|
|---|---|
|
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 <br>" patches applied, and completely reworked HTML parsing mode. May the Source be with you!
|
| Orkan |
|
|---|---|
|
"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 Perl - the only language that looks the same before and after RSA encryption.
|
| Trustmaster |
|
|---|---|
|
The parser situation is quite clear now.
What about the rest pluggable functions Tefra mentioned? May the Source be with you!
|
| Trustmaster |
|
|---|---|
|
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? May the Source be with you!
|
| Kilandor |
|
|---|---|
|
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 |
|
|---|---|
Kilandor: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:Sounds good. Really worth implementing. May the Source be with you!
|
| Kilandor |
|
|---|---|
|
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 |
|
|---|---|
|
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.
May the Source be with you!
|
| Orkan |
|
|---|---|
|
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? Perl - the only language that looks the same before and after RSA encryption.
|
| Trustmaster |
|
|---|---|
|
Some people REALLY want to, so why not give them a huge piece of happiness? :satisfied
May the Source be with you!
|
