Blog

If you run the function, the class will init

Calling from the depths of hollywood, I think it’s safe to say not everyone wants random ghostlike baseball players on their farm. As an example of this, I think we should start implementing some sort of class shift from inclusion by default into inclusion via need.

So, instead of the entire site loading up PodAPI and all other classes on every page load, I believe using the following will provide the best solution long-term.

So running $api = new PodAPI(); or $pods = new Pod(‘podname’); would actually map to a function which includes the real class object itself. This would be for backwards-compatibility, in which future use would be through $api = pods_api(); and $pods = pods(‘pod_name’);

Make sense? Throw rocks if you don’t like this idea, but if you throw rocks I’ll make sure it snows more in the north east with my fancy weather producing satellite.

11 thoughts on “If you run the function, the class will init”

  1. Also, I’d like to also propose the Import / Export code be ported into it’s own class and out of the normal day-to-day operations of PodAPI() — anyone have any naming thoughts here – was thinking maybe PodDataAPI() or something.. not sure.

      • Sounds good to me, I was thinking about that too, just want to make sure it makes sense and isn’t too long, PodMigrate() sounds like a great fit, will see what everyone else thinks

    • What kind of export/import options will there be? For instance doing either one from PHP, CSV, MySQL, etc.? And are there any ideas for field mapping being tossed around?

      • import / export will use one function each, which handles the bulk of the work – subbing out to a function for each format to either convert from or convert to. PHP / CSV (or other separated values) / XML / JSON / MySQL are definitely options for both import and export.

        What are your thoughts on field mapping?

        • I’ve used a few programs that included field mapping as an option when migrating data from an offline template in to the application or from a completely different type of application and importing it in to the application. Would there be any possibility in offering a point and click mapping option? For instance having the import script intercept the file upload in the admin and then offer a mapping screen before running the actual import?

          I’m more or less thinking of this in the practical sense of a user moving from Drupal to a WordPress/Pods platform and similar scenarios.

          • Actually, the import / export script will allow for mapping via the API, but the UI is a separate beast and I can see use in what you’re talking about here for 2.x

          • I concur. Being able to migrate a project from Drupal to WordPress/PodsCMS by modeling your Pod(s) out and then point and click field mapping can be extremely powerful.

          • Being able to migrate a project from Drupal to WP + Pods would be a great ‘built-in’ template, in which you can maybe migrate “automagically” just by giving the drupal table prefix name and the content types you want migrated 😉 maybe we can do a “conversion” script that would build your Pods out for you too..

Comments are closed.