get rid of the PHP components

[tabascoeye]

All that crusty old PHP has to go. The main thing it really does still is getting the RNV content and the non-graph Xively data which can all be done in JS.

Maybe even use a new framework for it all like Angular.JS (suggested by the brahson @else )

[elsbrock]

latest web shizzle, fo real

[echox]

AngularJS is a MVW framework, not a "lets put some components on a page" lib :-P

If you wanne be a webhipster, I think http://www.polymer-project.org/ is the thing for the job? :D Or just use jquery :D

[elsbrock]

watch out, looks like we have an expert here :p

[tabascoeye]

It's interesting how I find more and more negative comments when something is using jQuery which was the ultimate new web technology a while ago. I'll look into both...

[tabascoeye]

Wow. Okay. With something like polymer I really need a good IDE. When you have an arbitrary number of new Tags in your HTML which are inclusions of components, you need a "click to get to the declaration" style IDE.

Any Ideas? aptana?

[elsbrock]

No idea. No experience with that. You may wanna have a look at the Polymer I/O videos on Youtube, maybe you can see what the Google guys are using.

[echox]

How are you intending to get the RNV data via Javascript? What about x-domain security?

[elsbrock]

ezpz, proxying

/rnv => http://efa9-5.vrn.de/vrn/XSLT_DM_REQUEST?language=de&itdLPxx_dmlayout=gadget&itdLPxx_gadget=version_1.0.5&timeOffset=3&type_dm=any&mode=direct&limit=8&useRealtime=1&locationServerActive=1&anySigWhenPerfectNoOtherMatches=1&anyHitListReductionLimit=40&anyMaxSizeHitList=550&name_dm=6002359

By the way, where is the infoscreen served from? Please add the URL to the repo description.

[echox]

? Proxying via what? Isn't the intention behind that infoscreen runs completly client side?

[elsbrock]

Proxying via the webserver that provides the infoscreen.

[echox]

aaah sorry, I wasn't aware that we really need a web browser.

If we skip the "itdLPxx_dmlayout" layout parameter, we will get a 100% component without any "gadget" style. Should directly work in a div container, so should be no problem to get rid of that RNV.php

[tiefpunkt]

IIRC the infoscreen in the space is running locally on the rpi powering the screen. For the outside world, it's available at http://cosm.tiefpunkt.com/infoscreen. The RZL Space API endpoint is also located there.

[tabascoeye]

Okay so we need to keep

• /PachubeAPI/
• ajax.php
• spaceapi.php

we can get rid of rnv.php and calling the ajax.php in main.js (and use xively.js instead)

sounds half-way decent to me. Maybe the spaceAPI endpoint should be its own repo though?

[tiefpunkt]

It's in here because it needs the same sensor values, and just uses the same caching. But yes, might make sense to move it into status.raumzeitlabor.de or its own repository.

[tabascoeye]

If we skip the "itdLPxx_dmlayout" layout parameter, we will get a 100% component without any "gadget" style. Should directly work in a div container, so should be no problem to get rid of that RNV.php

nope. When that is removed, the response doesn't contain any time table as HTML. I found "vrn" to be a nice layout: http://efa9-5.vrn.de/vrn/XSLT_DM_REQUEST?language=de&itdLPxx_dmlayout=vrn&timeOffset=3&type_dm=any&mode=direct&useRealtime=1&locationServerActive=1&name_dm=6002359

But that would still need quite a bit more parsing work than using the gadget layout and stripping the "width=150px" from the one it's in.