Open michalkleiner opened 8 years ago
+1
Thanks for this! I wonder if it would be preferable to stick with the SS convention of private static $singular_name
and $plural_name
instead of getShortcodeNiceName
? This can be accessed on any DataObject through the existing singular_name
method, which falls back to a nicely formatted version of the data object's class name. Subclasses of ViewableData that are shortcodable would need to implement these directly.
getShortcodeKeyword
method also seems like it would be more suited to being a static config. Thoughts?
Well, we could use $singular_name as a default and still have the possibility to overwrite it if with a custom method if something different is needed?
@wernerkrauss yeap sounds good, how about first the module checks for the object's $shortcode_name
config value, with a fallback to singular_name()
method
shortcode_name
and shortcode_keyword
both seem more suited to being static config values than methods but please let me know if you think they should be methods for any reason I might be missing :)
Well, DataObject has a singular_name() method which does a fallback (basically for getting the singularName out of the class name if it's not defined and to get translations).
Do we need translations? Maybe for keyword, but not for the shortcode name, as this must fit to the classname we use for getting the shortcode rendered. Thinking about it, translating the keyword sounds very sexy to me.
I'd like methods we plug to DataObject via an Extension class, this is most flexible. Then the shortcode can rely that the method exists on the DataObject and we could overwrite it if needed.
Issue #10
This change adds an option to assign more descriptive name than the classname (appears in the modal dropdown) as well as select a keyword placeholder for the wysiwyg editor.