So this is the code I came up with... I could not find a CASE in the lua manual so I used ELSEIF... this lua is a lot like COBOL... even to the point i noticed of requiring DATA DIVISION and PROCEDURE DIVISION and so on... :lol: --- insert-all-html.lua --- -- this is used to replace the insert_html -- but with insert-html so both are still available. -- -- this file is my Aoirthoir but honestly all the code -- is from Daniil so i am putting his name down and he -- can get rid of this garbarge text here because -- he writes much better explanations than I ever will anyhow. -- -- Minimum soupault version: dunno... -- Author: Daniil Baturin -- License: MIT -- -- DATA DIVISION. -- WORKING STORAGE SECTION. selector = config["selector"] html = config["html"] action = config["action"] -- PROCEDURE DIVISION. if not selector then Plugin.exit("No selector chosen") elseif not html then Plugin.exit("No html chosen") end if not action then action = "append_child" end elements = HTML.select(page, selector) count = size(elements) index = 1 while (index <= count) do if action == "append_child" then HTML.append_child(elements[index], HTML.parse(html)) elseif action == "prepend_child" then HTML.prepend_child(elements[index], HTML.parse(html)) elseif action == "insert_before" then HTML.insert_before(elements[index], HTML.parse(html)) elseif action == "insert_after" then HTML.insert_after(elements[index], HTML.parse(html)) elseif action == "replace_element" then HTML.replace_element(elements[index], HTML.parse(html)) elseif action == "replace_content" then HTML.replace_content(elements[index], HTML.parse(html)) end index = index + 1 end --- And this is the soupault.conf section as i am using it... --- [widgets.add-hr-to-h2] widget = "insert-all-html" selector = "h2" html = "<hr>" # action = "append_child" # action = "prepend_child" # action = "insert_before" action = "insert_after" # action = "replace_element" # action = "replace_content" after = "insert-footer" --- This is a test signature.
I have asked someone that i work with to clean up the commentary at the top, make it better following the patterns of officially released plugins, including authorship, copyright, license, descriptions and howto... that way all my plugins can still contain all the very very important COBOL structures in the comments... -- PROCEDURE DIVISION rather than -- Plugin code because that is vital important to me.. im not even kidding even tho i am kidding :D
On 4/7/20 11:05 AM, Aoirthoir An Broc wrote: > I have asked someone that i work with to clean up the commentary at > the top, make it better following the patterns of officially released > plugins, including authorship, copyright, license, descriptions and > howto... > > that way all my plugins can still contain all the very very important > COBOL structures in the comments... > > -- PROCEDURE DIVISION > > rather than > > -- Plugin code > > because that is vital important to me.. im not even kidding even tho i > am kidding :D Lua is indeed a bit of a COBOL era language. Modern Lua is _somewhat_ better, but as Alan Perlis said, a language never leaves its embryonic sack... One additional problem with upgrading the language is that the official PUC-Rio Lua doesn't have a great record of backwards compatibility, so implementing a 5.x will (technically) break compatibility with old code. Since soupault is the only real user of Lua-ML so far, this issue is somewhat academic, but in general the long-term strategy for Lua-ML is an interesting question. Maybe in a long run, using Ramsay et al.'s approach for a different language (e.g. Scheme) is a better thing to do. More to the point, since 1.8 there's `Plugin.require_version` function, so new plugins should better use it than just specify required version in the comments. Since there are no reasons not to update to latest 1.x (compatibility is preserved), I think it's safe to use `Plugin.require_version("1.8")` for all new plugins that only make use of functions from pre-1.8 era. As of rewriting built-ins as plugins... most of the built-ins predate plugin support, and early on it wasn't even clear if plugin support was possible. I don't think it's a good idea to remove built-ins or stop working on them, but I think writing plugins that provide alternatives to built-in functionality is a good and valid thing to do. Right now it's not possible since, for example, lists of values cannot be passed to plugins from the config. When a new TOML library is in place, it will be easier.
Well so far I like the cleanness of Lua and your OCAML code. PHP and the like are burdensome as far as I am concerned with their needs to end statements with ; for no reason. In COBOL statements can be ended with a period if you want, and that makes more sense. Or END or END-THING such as END-IF, END-PROCEDURE.. all are suitable. The plugins so far are easy to create i just have to learn the language and structures. I will do that with plugin required... i just didnt know what version it required for what I had done. I will put that in the IDENTIFICATION DIVISION. (which is just a comment) That makes sense about not rewritings plugins. The toml library sounds exciting. Thanks for the help.
For the record ive cleaned up all the "COBOL" comments out of the code. It was fun while it lasted but now the comments strictly deal with what the plugin does and the Lua code of my plugins is a lot smaller as well.