Hi Björn, Hi Oliver, Hi Keywan, Hi Thomas, >> But one question: Can you describe the difference to a nice composer setup? A lot of people ask this question after only seeing the main repository ( github.com/ioly/ioly), which only really details the ioly-Core-PHP File. ioly gets a lot more interesting when it is used within in other modules, for example with the ioly OXID Connector: https://github.com/ioly/ioly/tree/connector-oxid, which gives administrators a GUI on top of ioly which, for example, could only show packages relevant to OXID, or could check extra things that composer doesn't check, e.g. OXID version, Zend, etc. etc..
Composer is great if you have a nice automatic dev > stage > live workflow, maybe coupled with git/hg etc.. It works well, and does the job. We (gn2) use it internally too, in combination with the OXID composer-installer changes from Dirk Bloessl, but it usually involves making your own private repositories and faffing around with composer.json-Files (or convincing module developers to add their own composer.json), which a lot of people don't have the experience or time to do. To publish your own packages, you have to use packagist (or your own satis setup etc.) and we didn't think packagist is the right place for OXID Modules, as they can't really be considered as "generic reusable php packages". We see ioly and composer as two different things. We built ioly not as a composer replacement, but as an effort to improve the OXID community. At the moment, there are modules everywhere and each module has been discovered only by a few agencies, and each only use the modules they have tested. Some are in VCS, some are just ZIPs, some aren't even modules at all, but just helpful snippets. Nobody really knows which modules are available out there, which module works with which version etc.. Also; every module developer has their own workflow. They shouldn't have to deal with composer to publish their own packages. ...so we thought we would try the idea of a central repository that anyone can fork/improve. It has the advantage that module developers do not need to change their workflow at all. All they need to do is offer their module as a zip-file somewhere. It is not even necessary that the developer know about ioly: *anyone* can send us improvements to the ioly cookbook in the form of pull requests: https://github.com/ioly/ioly/tree/master/oxid, which means theoretically, if the company Marmalade finds a nice module from Vanillathunder, they can send us a new recipe file file. It then gets discussed, openly, on github, and if the community finds it useful, it gets merged and appears in every ioly-OXID-Connector installation -> this means everyone always knows what is available. >> can it be used together with composer or does it have it’s own way to handle dependencies? composer: yes dependencies: no. not yet. maybe. we're waiting for more recipes first. >> And another question, is there a way to connect ionly with oxid exchange? Hell no!* *Well actually, yes. If some keen OXID-exchange developer included the ioly.php-File in Exchange, they could read out all available OXID packages regularly and present them as 'buyable' download products. ioly works over the command line too, so it also work in a cronjob which would regularly update the articles in Exchange. >> from business point of view one click install sounds as a nice feature, but seriously? :) >> letting end user with limited knowledge install modules into oxid? giving permissions to f*** up the system? True, but the same can be said about encrypted modules. There is always a layer of trust that they aren't sniffing $_POST['order']['cc_number'] and sending it off to the Lithuania-Pastebin. This is the PHP equivalent of letting a baby use an iron. Dave
_______________________________________________ dev-general mailing list [email protected] http://dir.gmane.org/gmane.comp.php.oxid.general
