Skip to main content ↑ ↓
package-info.xml to... .something else? Started by emanuele · · Read 6291 times 0 Members and 1 Guest are viewing this topic. previous topic - next topic

package-info.xml to... .something else?

I hate writing XML.
It seems that nowadays, JSON is a more "readable" (and writeable :P) way  to handle data.

What do you think about introducing JSON as "default" language for package-info?
Bugs creator.
Features destroyer.
Template killer.

Re: package-info.xml to... .something else?

Reply #1 –

Much easier to handle too. One call.

Re: package-info.xml to... .something else?

Reply #2 –

Yup, writing the package files is a pita !

Re: package-info.xml to... .something else?

Reply #3 –

Then the schema! O:-)

The current XML has quite a bit of options.
I guess they could be organized in several different ways.

One proposal:
Code: [Select]
{
	"id": "emanuele:myaddon",
	"name": "A demo mod",
	"type": "[avatar|language|modification]",
	"credits": "A string of credits.[br]It may contain bcode because we [b]don't[/b] want HTML in here.",
	"hooks": [
	{
		"integrate_something": "myfunction"
	}
	],
	"[install|upgrade|uninstall]": [
	{
		"for": "1.0 - 1.0.99",
		"from": "1.0 - 1.0.99",
		"readme": {
			"filename": "myhelpfile.html",
			"lang": "english",
			"parsebbc": "[true|false]",
			"type": "[inline|file]"
		},
		"[code|database]": {
			"filename": "myinstall.php",
			"type": "[inline|file]"
		},
		"modification": {
			"filename": "mychanges.xml"
		},
		"[require|create|move|remove]": [
		{
			"dir": {
				"from": "path/to/dir",
				"to": "ADIRCONST"
			}
		},
		{
			"file": {
				"from": "path/to/file.php",
				"to": "ADIRCONST"
			}
		}
		]
	}
	],
	"redirect": "?action=myaction"
}

I may have missed something...
Bugs creator.
Features destroyer.
Template killer.

Re: package-info.xml to... .something else?

Reply #4 –

good idea
json simple and trendy

Package SDK: package-info.xml

Spoiler (click to show/hide)
Sorry for my English

Re: package-info.xml to... .something else?

Reply #5 –

Yep, that's another option as well, I was not sure what has the best readability: have multiple "attributes" like "require-dir", "require-file", "move-dir", "move-file", "remove-dir", "remove-file", "create-dir", "create-file", or just specify an "action" (require/move/remove/create) and then an array of "items" to which the action applies.
I proposed the "compact" just because I'm lazy :P
But probably the multiple stuff is easier to map to the current schema.
No strong opinions.
Bugs creator.
Features destroyer.
Template killer.

Re: package-info.xml to... .something else?

Reply #6 –

Waiting for this feature for sure O:-)

Re: package-info.xml to... .something else?

Reply #7 –

So long the samples are there. No problem with me too. I'll ask if I do not understand later.

Re: package-info.xml to... .something else?

Reply #8 –

After about 3 months, reading this topic, it sounds like a waste of time.

My "idea" is to arrive to a point where addons would need just a php file dropped in the right place to do everything.
I'm moving towards this goal with my current work at:
https://github.com/emanuele45/Dialogo/tree/playing
it's still very, very WIP, so if you have suggestions or ideas feel free. ;)

How does it work?
First the dispatcher loads "certain files" based on their position and naming:
https://github.com/emanuele45/Dialogo/blob/playing/sources/SiteDispatcher.class.php#L360
that means at the moment any file that looks like:
Code: [Select]
/path7to/forum/packages/integration/my_addon/my_addon.integrate.php
it also registers to the "event manager" a name prefix:
https://github.com/emanuele45/Dialogo/blob/playing/sources/SiteDispatcher.class.php#L322
the event manager looks for any class loaded whose name starts with that prefix:
https://github.com/emanuele45/Dialogo/blob/playing/sources/subs/EventManager.class.php#L91
and registers the hooks it finds:
https://github.com/emanuele45/Dialogo/blob/playing/sources/subs/EventManager.class.php#L108
the event manager expects to find a certain (static) method inside the addon class: hooks that should return an array with some informations:
the class and the method to call,
 the priority this class/method has,
the "event" this action should react to,
 the dependencies (in terms of variables).

All this stuff means I changed quite a bit how the "hooks" work.
In the code above, hooks are now "events" managed by the event manager and "triggered".
https://github.com/emanuele45/Dialogo/blob/playing/sources/controllers/Mentions.controller.php#L380

So, the difference with the current system is that an addon, to create a new kind of mention could just add a file in the proper place, no need of "add hooks" to the database, no need to instruct the system where the file is. Just put the file where the system expects it to be and everything else will happen by magic.
Thus no need for a package-info.xml/json/whatever at all.
Bugs creator.
Features destroyer.
Template killer.

Re: package-info.xml to... .something else?

Reply #9 –

I like very much the idea of moving to an event based system.  I know thats just preliminary code but the use of the cache will come in handy in a few areas so we don't have to troll the file system to find the addons.

I'm not sure this replaces the use of the package file, but certainly the add/remove hook stuff.  Addons still need to install language, template, subs, controllers, etc etc I suppose that could be done by dumping them all in some addon/subdir location and just loading from there.

On the templates, one thing I still struggle with is what if two addons want to make changes to the same template, seems like only one will win if its an override / replace solution?

Re: package-info.xml to... .something else?

Reply #10 –

On the theme I have some ideas as well, but is probably too early (also because are still very foggy in my mind... lol).

Good point on the two addons wanting to change the same piece and... no, no idea.
Do you have in mind any example of how and where such a conflict may appear?
In general, I guess the result will be that the last one will win, yes. That is more or less the same problem we are facing now, just reversed: the first installed is likely to be the one that wins because the other may fail.
One possibility may be to convert some/most/all of the templates to return functions and give the addons a way to manipulate these chunk of strings (similar to the poster div).
Bugs creator.
Features destroyer.
Template killer.

Re: package-info.xml to... .something else?

Reply #11 –

No I don't have an example, was just thinking about that situation looking at the code.   I can see two addons installing a new button in the template but fighting over which template wins.  

return functions may be the only solution for those areas that tend to get the most addon traffic, at least you would have a chaining effect..

Re: package-info.xml to... .something else?

Reply #12 –

I moved the discussion about the quick reply to:
http://www.elkarte.net/community/index.php?topic=2153.0
Bugs creator.
Features destroyer.
Template killer.