Available Extension Display

[mithra62]

One thing that we should at least start thinking about is an easier method of displaying the available extensions installed. Depending on how implementation is done by other devs and their add-ons EEDT extensions may be buried within other extensions so management of EEDT stuff could be an issue.

Christopher had mentioned something about using a Git repo to contain this info though I'm not 100% on what's involved there. Christopher, can you elaborate?

Regardless of how we approach this, I was envisioning a dedicated page within EEDT that would take the "master list", compare it to available extensions on the system, and display anything on the master list and on the system. Simple enough. From there though, we could handle management of EEDT CRUD and keep things organized for users.

[ckimrie]

So I got the idea of a central Git repo listing all known EEDT extensions by seeing the Phonegap Plugins repo. Although the repo could store the code itself, they are now recommending that each 'folder' that represents a plugin merely has a README.md file that describes the plugin, author and the loctation to download the files. Here's an example.

This technique allows a central listing of addons to be easily linked to, but also alleviates the headaches of maintaining the plugins since we are merely linking to the original source code.

This doesnt help with your idea (which I like) of having a dedicated page within the EEDT that lists available extensions though.

[mithra62]

The main platform storing the code is one of the painful parts of writing WP stuff; yuck. Agree, let's just have a simple repo with a file, inside a folder of the add-ons name, that contains meta data that devs can do pull requests against to add their add-on.

It should be simple enough to just hit the Github API for the repo to pull that info into EEDT. From there it's straightforward enough I think.

[ckimrie]

I thought you could only hit the Github API with valid OAuth credentials? Or is there a public API we can hit?

[dpdexter]

Just an idea..... Could you simply grab the 'raw' version of the file with curl?

For example: https://raw.github.com/mithra62/ee_debug_toolbar/master/README.md

[ckimrie]

Thats a good point. I guess I was envisioning a folder structure like the Phonegap plugins repo. No real reason why we couldnt actually just have a single README.md file with a list containing each addon name, developer, brief description and link

[ckimrie]

Not as structured I guess, but at this point it is simpler.

[mithra62]

Well, we could go with an XML file and link directly to that? I just checked and this link works: https://raw.github.com/mithra62/ee_debug_toolbar/master/themes/third_party/ee_debug_toolbar/themes/default/images/db.png

We could just have devs fork that repo, modify the file, pull request, we verify, merge.

[dpdexter]

I don't see why an xml or json file wouldn't work. I just don't know if its against any terms of service from GitHub (I doubt it would be considering their overall philosophy)

[mithra62]

XML would be easier to edit and visualize so that's my vote.

[ckimrie]

ermm, I'm for JSON....

[dpdexter]

I can respect that... Turns out your vote is really all that counts here anyways ;) Its your (amazing) contribution.

[mithra62]

Thanks! Nothing gets done without Christopher weighing in though :)

[ckimrie]

Well. This is awkward.

[dpdexter]

ut oh... a mutiny. Well I know my vote is useless... but I'd have to side with Christopher on this one ;)

[mithra62]

See! democracy in action. JSON it is.

[ckimrie]

:+1:

[mithra62]

In fact, I guess this begs the question of using XML on the panel cache like we're doing. I mean, it seems sort of wasteful to use both XML and JSON when 1 will do. In fact, now that I think about it, it'll likely remove about 300 lines of code by moving to JSON for that...

[ckimrie]

I guess I am more comfortable storing that much data in XML simply with regards to unescaped characters when inside <!--[[CDATA tags. But I think JSON is far easer to read/write since you dont have to duplicate open close tags.

[dpdexter]

Aren't you using the json_encode php method anyways? It will handle the escaping for you.

[ckimrie]

I appreciate heavily nested JSON is a bitch to read and write, but in this case it will only be a shallow array of objects that is only one level deep

[ckimrie]

@dpdexter true.

I suppose the only consideration would be having to run the debug output through json_encode on every page load. The SQL and Template debug output is pretty bug, so not sure if thats gonna run us into trouble.

[ckimrie]

Although come to think of it, I dont know how that stacks up against shoving into SimpleXML, which is what we are doing right now. Without numbers, I have no idea which is more performant.

[mithra62]

If only there were a tool, for ExpressionEngine no less, that made benchmarking these sorts of things easy...

[dpdexter]

http://gettingreal.37signals.com/ch04_Scale_Later.php I wouldn't lose sleep over the SimpleXML v. json_encode performance issue ;)

[ckimrie]

Fair point. Just thinking out loud

[dpdexter]

yup. I love a good 'think out loud' session... especially with people that are smarter than I (thats most people)

[mithra62]

Just to kick things off, I've setup a new repo just for the add-ons: ee_debug_toolbar_addons. Inside will just be a file called "add-ons.json" that'll contain the meta data we'll need for when dev starts.