SCEditor
SCEditor copied to clipboard
samclarke
Look into creating BBCode dialects
Look into creating BBCode dialects to make it easier to use the editor with things like phpBB, SMF, MyBB, etc. That way users could include the editor and the right BBCode dialect and that would be it, done.
Currently making SCEditor work with a particular dialect requires adding / updating / removing BBCodes which requires learning a lot of how SCEditor works to do it. It also makes it harder for those BBCodes to be shared.
To do this would require a build of the BBCode format without the default BBCodes which would also fix #402. It should be able to be done in a backwards compatible by having a file that bundles the BBCode format with a dialect that matches the current default.
I use only phpBB, so don't know how other dialects are different. In 95% current BBCode matches with phpBB needs... most of the basic functionality is probably the same for all the dialects.
Why not keep that basic functionality as a core of the bbcode format and move the rest of the functionality to plugins? The dialect will be configured by including the right plugins into the configuration options. Ideally, all buttons functionality could be moved to plugins and included as a basic set of functions. Don't know how it will impact the performance on initialization...
Didn't check it, but If plugin can override existing core implementation, so the transition could be pretty simple, keep the core implementation to keep backward compatibility and override the functionality you would like to change (or add new codes with new plugins)...
In 95% current BBCode matches with phpBB needs... most of the basic functionality is probably the same for all the dialects.
I've tried to match the most common formats for the default BBCodes which works but even BBCodes like font size and colour vary as well as the white space in lists.
Why not keep that basic functionality as a core of the bbcode format and move the rest of the functionality to plugins?
That's essentially what dialects would be but instead of having to add lots of plugins users can just include the right dialect and everything is done. With plugins there would either have to be a separate one for each BBCode variation or they would have to be configured.
Dialects can include all the supported BBCodes for that system and configure them and the white space handling to match that dialect. The idea is they would be sort of like a plugin that bundles a bunch of other plugins (BBCodes in this case) into one and configures them correctly.
Ok, so that's about the same thing I was thinking as well...
When plugins are initiated? If it's done in very early stage, before the configuration options are processed, we could have a "dialect-plugin" that will add the needed "format-plugins" into the configuration options (+ other option changes if needed) and the rest of the things will continue as they are today.
As an SMF developer, I like this idea in theory. However, to make this sustainable you would need to work closely and collaboratively with the developers of each of the platforms you want to support. Otherwise, keeping up with changes over time in the various BBCode dialects will become a nightmare for you and for the platform developers. It might be best to set up discrete repositories for each dialect plugin and invite the developers of SMF, phpBB, MyBB, etc., to participate in them.
As an example, in the upcoming version of SMF, we now support both [url=http://www.example.com]...[/url] and [url="http://www.example.com"]...[/url] syntax (until now we've only supported the former). Implementing this required changes both to our internal PHP code and to our customized SCEditor code, which all had to be implemented at the same time. It would be a problem if we had to coordinate such changes in our code with changes in an outside repository to which we had no direct access.
@Sesquipedalian
Why don't you implement both versions of the [url] tag in PHP and remove the deprecated implementation only after you start using the SCEditor without the "" in url?
I don't even dream to use Sam's repository directly since I have some local adaptations that are useless for others that I keep in my repo and use the changed version. I believe other "heavy" users will do the same. I don't see a reason why Sam should coordinate with other developers to keep track of their dialects. Every system could fork its own repository and continue there. Pushing the changes to Sam's repo will help everybody stay in sync with all the bugfixes when they rebase. If SMF would have such repo and make it available for their users, so you, as a SMF developer, could keep track of the dialect changes that are tightly bound to SMF's changes.
As I saw in some comments somewhere, there are forum developers who want to use SCEditor, but don't want to invest their time to make the needed changes and demand that from Sam, which doesn't seem right to me.
@abetis We do have it implemented in our own code, and it is all working just fine. You have misunderstood the meaning of my comment. My explicit point is to say that if Sam wants to maintain his own code to handle different software's BBCode dialects, an arrangement like what I described would be necessary. My implicit point is to suggest that Sam would probably be better off to leave it to the different forum software developers to manage our own customizations for ourselves, as we already do now.
If @samclarke's goal is to make it easier for forum devs to implement our particular dialects of BBC, a more viable solution would be to move all the default BBC definitions out of bbcode.js into a bbcode_definitions.js file and just leave it at that. Then when SMF or phpBB or whoever implements SCEditor, it would be our responsibility to edit bbcode_definitions.js to match our particular dialect. That would work out much better for everyone than if Sam tried to maintain versions for all the different dialects himself.
I agree that codes implementation should be separated from the engine logic, but I think it should be a "default" set of codes and every dialect override the ones that they want.
I think there are lots of the codes that are exactly the same for all the dialects ([b], [i], [u] etc.), so we better have them in one place and not duplicate the code.
That should be the base:
https://www.bbcode.org/reference.php
I still don't understand why you think Sam should provide the repositories for every dialect and not the forum developers who can clone the main repo and work there. Once @samclarke will provide the infrastructure, everybody could create its own dialect and propose the changes to Sam's stream. The main stream should concentrate on the engine, the base bbcode implementation and keeping order between different implementations, so all will use the same APIs and principles. That's my opinion...
@abetis, there seems to be some miscommunication here.
I agree that codes implementation should be separated from the engine logic, but I think it should be a "default" set of codes and every dialect override the ones that they want. I think there are lots of the codes that are exactly the same for all the dialects ([b], [i], [u] etc.), so we better have them in one place and not duplicate the code. That should be the base: https://www.bbcode.org/reference.php
That's the same plan as the one I am proposing. So, we agree with each other. I am not sure why you think we are disagreeing.
I still don't understand why you think Sam should provide the repositories for every dialect and not the forum developers who can clone the main repo and work there.
The problem is simply that you misunderstood what I wrote. I did not say that Sam should create repositories for different dialects. I said that if Sam really wants to offer a multitude of dialect files for download himself (as described in the first paragraph of his original post), he would need to do something like that. "Would" !== "should". I don't think he should try to maintain multiple dialects himself. I was only describing what would be required if he were to try to do that.
I actually already built an engine that uses a 3rd party lib which helps translating a BBCode definition into generic BBCode rules and then my code translates into SCE BBCode definitions which are meant to power SCE's BBCodes. It is a nearly-complete, near feature-complete project which went wrong when some unexpected features appeared in phpBB's BBCodes.... It dragged for long.... The code still works just fine (I tested it in February this year) but it requires a few detail fixing for the (at the time) new quote tag
@Sesquipedalian Leave the should/may/must aside, that's not the point... My question is why it didn't happened yet... A pretty stable SCEditor is around for a while already. Looks like forum developers/owners want to use SCEditor, but no one does nothing to get SCEditor main code closer to their usability. Anyone can fork the repository and develop there its own dialect using the existing APIs, invite the developers and push the changes/bugfixes back to the original repository for the benefit of everybody else.
@brunoais I think if you have an utility, it should be a separate project and not part of the SCEditor. It will be nearly impossible to have both in sync all the time.
My question is why it didn't happened yet... A pretty stable SCEditor is around for a while already. Looks like forum developers/owners want to use SCEditor, but no one does nothing to get SCEditor main code closer to their usability.
🤨 Many of us have submitted PRs to SCEditor over time, when the changes were ones that appropriately belonged in SCEditor's core. When we need customizations tailored to our specific needs, we keep those customizations in our own repositories because that's the appropriate place for them. I'm not sure why you think something else has been going on or why you think it should be different, but the collaborative relationship between @samclarke and the various forums that use SCEditor has been working quite well for years now.
Don't know... Maybe I'm new here, but I didn't see any basic support for a widely used phpBB format. All I could find are blames on @samclarke that he does not cooperate with the developers requests.
Anyway, @samclarke, my final comment as I exit this conversation is that it is probably best to simply move all the BBCode definitions into a separate bbcode_definitions.js file and leave it to the different forum platforms to customize that file to match their specific dialects.