I am getting quite unimpressed with all the JS boilerplate and spaghetti code we have to write to achieve simple AJAXification. I don't think a JS framework is something realistic with everything tied to Elgg's view system, so I am thinking more and more about using Elgg as a data provider and creating UI on an AngularJS or ReactJS stack.
Here are some issues I have bumped into while playing with this:
I am not sure Elgg needs (or is capable of embracing) a JS framework of its own in the near-term future. Given the variety of frameworks out there, I would much rather have an option to choose and switch whenever I want, who knows what's the next big thing after React. If we can turn Elgg into a better data store, I think we will start seeing more stand-alone bootstraps for various JS frameworks.
I have tried hard to envision Elgg as an Angular or React app, but it seems it will be easier to write a native JS app that uses a NoSQL database and all the latest JS tech than try to make the view system work with a JS framework younger than Backbone.
Anyhow, just sharing thoughts. I am getting tired of writing HTML in PHP, and going out of my way trying to achieve simple data-binding with jQuery.
info@elgg.org
Security issues should be reported to security@elgg.org!
©2014 the Elgg Foundation
Elgg is a registered trademark of Thematic Networks.
Cover image by RaĆ¼l Utrera is used under Creative Commons license.
Icons by Flaticon and FontAwesome.
- Cim@manacim

Cim - 0 likes
- Gerard@gkanters

Gerard - 0 likes
- Evan Winslow@ewinslow

Evan Winslow - 0 likes
- ihayredinov@ihayredinov

ihayredinov - 0 likes
- Steve Clay@steve_clay

Steve Clay - 0 likes
- Evan Winslow@ewinslow

Evan Winslow - 0 likes
- Gabriel Vargas@vabel

Gabriel Vargas - 0 likes
You must log in to post replies.It would be nice to popular an entity list via JSON.
Very interesting thoughts, I was wondering why the web_services are not maintained while it would be good to have this as an always available route to data. It needs to become more robust then with API key management, rate limiting, exposing services to the outside from admin panel, etc..
I also thought the page handler of elgg is somewhat complex but thought that this was my issue.
A good webservices API and JS framework for the frontend, combined with HTML5 might be the best way forward and attract new developers. It also would make it possible to have a better split in front end developers and backend. Currently frontend and backend are very much tied into the plugin structure and php API
Me personally have to upgrade my js (angular an jquery) skills, but I am definitely willing to do that.
Agree with the sentiment, here. I'd be delighted to work with you on the next iteration of routing for elgg. Hopefully something that would make it trivial to expose web services and not cumbersome.
One thing I don't see anyone doing that could set us apart is focusing on controllers as a model for http resources. So they have methods that map directly to http methods. This would hopefully keep the learning curve low. The methods could just return anything json serializable and you'd have a json api by default without any extra effort. Any other rendering to HTML or RSS or whatever would be another layer on top of that.
I'd also like to avoid writing our own dispatching code. That seems like the meatiest part. Slim could be fine, but I'm partial to the {curly} syntax of FastRoute and Laravel.
I also think named routes are a requirement but they're something of an afterthought with laravel. FastRoute had a very compelling and thorough analysis of why their approach was fastest, so that's my current favorite right now. Speed is not something Elgg is known for. It couldn't hurt to focus on it a bit more...
One thing I also liked about laravel is the method injection. So services get injected straight into the controller methods, rather than having to pipe them through the constructor. This cuts out a lot of boilerplate. And we could inject read-only services into get/head/options but writable services into put/post/delete. The performance benefits here are again nice for automatic caching guarantees, etc.
Once these pieces are in place we can really build a standard set of APIs for Elgg. Wdyt?
You are the boss :) Whatever we can do to make life easier for all.
I'm cool with moving to any routing system that adds features (but I would miss the capabilities of the route hook if it had to go). I suspect routing is seldom the performance bottleneck unless your app isn't doing much at all.
Well you may think of me as the boss because I assert my opinions strongly but I have no more authority than anyone else here. And I hardly have any time to implement any of these ideas myself. So really what I'm asking is: have I convinced you enough for you to go and implement this for the rest of us?
:)
Some examples of what's in my head to make things more concrete:
Now lets try with input params:
@evan i have done something similar for a new project i'm working on, it's quite simple, just tried to make something like Laravel's controllers. Check it out: https://github.com/enkeli/elgg-routes
it's not a final plugin, certainly it does need some work and testing. But i'd be glad on spend some time working on making something simimlar to the core.