Skip to content
This repository has been archived by the owner on Mar 9, 2020. It is now read-only.

DeveloperMusings

Michael Cummings edited this page Apr 6, 2014 · 1 revision

DeveloperMusings

Just a place to capture some ideas about development so they don't get lost.

Introduction

Everyone is welcome to comment here if they like some of the ideas they see here but don't take this as anything like a development road map they are just musings and other random thoughts about things that I don't want to lost before I really have a chance to look at them in the light of day so to say.

Objects

Should get back to finish off the Interfaces I was working on to let me change over to that system for all the APIs. Would make it easier to add new APIs and maybe move to using a factory pattern for them.

Done right I could also move to using a XML config file to replace the ini and probably re-use some of the API code. Think this would probably make adding an install/config script much easier too that everyone seems to think would be a good thing to have. Also see this allowing me to combine the common_backend.inc and the eve-api-pull.php. Would at least let me make common_backend.inc simpler it's starting to get out of hand the way I've been adding to it.


Comment by paulesim...@gmail.com, Jul 11, 2011

Suggest developing an abstract API for Yapeal turning the entire package into a black box usable via the API only for 3rd party applications that want to integrate Yapeal into their apps. This way all the internals can remain unknown to the end-users/developers, and they (hopefully) don't need to know anything other than the resultant 'Yapeal API'.

This suggestion was prompted by my attempts to integrate Yapeal with a Drupal CMS to be used as a template website for either Alliances, Corporations, or both. I'm using things like the abstract API's for different database drivers as models for design of the semi-abstract API between Drupal and Yapeal for now, but I'm still too new to be confident of the resulting design avoiding most future issues. Ideally, the Yapeal API should be (whenever possible) unchanging over time, but can be extended with new calls and functionality. The end-user need not know the underlying code at all, merely make the appropriate API call from whatever front-end they are using, whether PHP, Ruby, Python, or other appropriate language.

Just my 2¢


Comment by project member dragonr...@gmail.com, Oct 17, 2011

Actually been trying to move to something like that but by it's nature and design doing so has so far proven difficult at best with Yapeal.