Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In with Google Sign In with OpenID


edited June 2013 in Apps

Hi guys,

I was thinking about creating an App to retrieve the Elefant Data as JSON. The usecase I had in mind is using it for a singlepage App, which updates itself via ajax.

I set something up which returns controller->run data.

You can see the results here:

I now want to extend it and return also the data from the tables. Is there a similar easy way like controller->run or do I have to get the tables the way I did it for the page with $page = Webpage::query () ...

In this case it would have to be done for each single table :-(

Does anybody has an Idea for better identifiers for the includes in the /json/api/run/layout/ ?

Cheers betaman


  • Damn, this would be most useful! I'm somewhat relatively new to the ElefantCMS, so I can't help... but I would absolutely love to see this project finished.

  • That's pretty cool!

    I was just working on a new CRUD class myself that extends Restful with built-in create/read/update/delete methods for a given model, as well as a JavaScript wrapper for it. It sounds like they might be able to partly fill in the missing pieces for you. Here are the new files:

    I haven't updated the docs online yet, but there are lots of comments with examples in those two files.

  • Thanks for the examples I'll check them out. It looks like that's exactly what I was looking for, when it comes to manipulating the data :-)

    Is there a way to GET Data from the Controller uncompiled for Example $out = $this->controller->uncompiled ($url['host'] . $url['path'], $data) returning the unrendered Data of the table, with all the access isues taken care of, like ->run does?

    It could be done with the CRUD API, but you would have to add all the ressources manually. I think it would be awesome if there was a way to do it without configuring so that new apps would be in scope automatically (and of course sparing yourself from configuring each API call individually :-).

  • Do you mean to get the raw data from a handler before it is passed to $tpl->render()? If so, I think that would take modifying the handler itself to do something like this:

    if ($data['return_raw_data'] === true) {
        return $data;
    } else {
        return $tpl->render ('foo/bar', $data);
  • I dont want to modify any handler, I think it shoud be in the render function itself..

    if ($data['return_raw_data'] === true) {
        return $data;
    } else {
       do the usual render stuff..
  • I don't see how that could work without a change to the way handlers return values. What is the use case you're trying to solve? It sounds like I need a better idea of what you want to build before I could make a suggestion one way or the other.

    Usually if I need the raw data for something, then that thing should be moved to a method in the model layer. Handlers should be as simple as possible, connecting the request to some model interaction, passing that response to a view template, and back to the user.

    And if you're building a single-page app from regular handlers, this may be of interest:

    It converts an existing site into a single-page app by converting internal links into AJAX requests and live updating the current page and browser history. Really neat!

  • So one and a half years later, I feel I've made this viable. The core of it is basically a js file, an API class and a small benign change to the Page class, with a bit of extra JS thrown in to handle a few special cases when it comes to how scripts are setup differently...

    You can see it in use on one of my sites here: It's definitely still a work in progress, but I think it's reached a beta point. I'll put the code from this together soon™. Feedback is always welcomed.

  • Awesome! I'm looking forward to seeing the changes.

  • Here's the diff: I haven't made a PR yet because I'm still unsure if this would be the best route to take with integrating it into the CMS. It's a bit experimental, but it does work as the above website proves. (The core.js and files seem borked in git or something...)

  • Haven't looked at the JS yet, just the PHP changes, but this looks like a pretty cool solution! The change to the Page class is completely minor too, very nice.

  • Made a small change to the core to fix a loading order issue. It puts the scripts in 'head' before the HTML and the scripts in 'tail' after the HTML, to follow where the server says the scripts should be loaded. Would love to know what you think about the JS when you get time.

Sign In or Register to comment.