Just wondering if anyone has downloaded a liquid asset like layout/theme.liquid and parsed it successfully? I use Nokogiri which is up there with the best parsers, and it seems to totally choke on the Liquid... which is totally expected since Liquid is not well marked up HTML/XML.
Anyone care to share how they get around this limitation? Treating an asset like this as a string and playing with it seems rather 1982...
Would appreciate a tip or two from someone in the community that has pillaged an asset for it's lead and replaced it with gold...
If you MUST add or edit HTML and insist upon not using the Script Tag, then remember this: when an app is removed and you get pinged by the app/uninstalled webhook, write access is already revoked on the shop's theme so you cannot clean after yourself. Don't alter a theme's HTML/Liquid too much.
I am not "doing" anything wrong. A superficial parse of a run of the mill theme asset, eg: layout/theme.liquid, shows me there are some unexpected results due to the structure of the documents.
You can try and query the <head> for things like the Liquid asset tags, but you won't find them in the <head>. I found them instead in the body, as a p element with text. Go figure. It seems that since Liquid is just decorative, and can't live in the head of a well-formed document, my parser shreds Liquid into the body, thinking that is the least it can do for me.
I appreciate your efforts to inform me of "best practises" on forming an App, but this really has nothing to do with that at the moment. You cannot write a nice App, if you do not understand some aspects of what it is you're up against.
In my case, my App Installer now knows more about my theme than I do. It knows everything about what is there, and what is not. So I can now make an intelligent use of the API to augment my theme using proper techniques.
For example, I will not make the bone-headed mistake other Apps seems to sometimes be making, of inserting code that is already there. I will definitely add code through script tags that is needed, and I will probably add code to take advantage of existing libraries so as not to bloat a theme even more.
If you do not know your theme, and you inject scripts into it willy-nilly, then you will look silly...
Anyway, I figured out the issue, and I appreciate the tips.
I accept that my original wording is responsible for this mis-communication. In an abstract sense, all I want to do is ensure a THEME is augmented with the correct support code to run my Apps. ScriptTags will have to do since that is they're purpose. My installer will now try to direct the ideal scripts into a theme based on the fact that I can indeed audit what is currently driving a theme.