Jump to content

Frog Code - Required Features


Marcus Goluch

Recommended Posts

Hi all,

After using frog code to do some pretty fun things, i think its time to mention some of its weakness that I feel need to be addressed.

  • In the frog code editor, you can not delete an application or package by right clicking its name.
  • When creating new packages/pages the file browser (left side menu) closes all its nodes.
  • The default demo application shows you nothing about why you would want to use it over a widget.
  • There is no server level to widgets or applications, this is holding the platform back more then you guys know.
    • If I wanted to create a simple chat application, I could create the chat window as either a widget or application but will have no way to take a message from student A and pass it to students B and C.
    • If I wanted to create a classroom voting system, I have no way of saving which students have responded let alone what their vote was and as before I can't even get that data to the server.
      • Create a 365 spreadsheet set it to shared and then use java script on the user client to alter the spread sheet via a widget?
        • First, I can press f12 and get that documents url.
        • Second, I can then use this url to have unrepresented access to read and alter that data.
        • Thirdly, this way of doing it is absurd.

I am sorry to be the bearer of bad news, whilst having all this client-side functionality is amazing, without access to communicate and save data then we might as well stick to html widgets.

All round, I think we need to have either a php or java script implementation server side. Allowing us to create data containers weather that be in a frog specific way or with db access, sql or similar. We then need to be able to implement an ajax or jquery method to allow the client application and server applications to talk.

I am not saying I want unrepresented access to the server, I know that we techies could do a lot of damage with full php access such as reading copyrighted read files in frogs source code. However, sand boxing the server side scripting environment shouldn't be too difficult as this is commonly done in apis. 

 

I hope that many of the user here are in agreement with what I have to say, please don't take this the wrong way. I love your platform and I want to work more with it, but all the things I want to do currently are not doable.

 

Thank you

Link to comment
Share on other sites

Hi Chris,

All valid points.  I think its fair to say everything you mention is in the internal roadmap for FrogCode - but being honest, there is no development scheduled for FrogCode. 

While that might sound depressing, we're deliberately keeping the roadmap short these days so that we can be as responsive as possible.  

1 hour ago, Chris Goluch said:

...without access to communicate and save data then we might as well stick to html widgets.

For me, the difference between the HTML widget and FrogCode is for the end user.  @pconkie's Flash Cards is a great example of something a regular teacher would struggle to assemble in an HTML widget, whereas the awesome (and it is awesome) Secure Gateway widget will only be used by the admin setting up a page for SG.  Of course, the other major benefit is that the widgets are easier to share than code.

I'll do my best to keep you and the forums apprised with any development updates.

 

Graham

 

 

Link to comment
Share on other sites

@Chris Goluch @Graham Quince


Sorry it's taken me so long to see this, I've been busy beavering away at the shiny new things. I think what @Chris Goluch may find useful is the datastore in our FDP endpoints. We've not really mentioned these before because they are still in a state of flux, but they should go some way towards the things you mentioned.

FDP/2/datastore - which has the following methods available: (get, create, createMany, update, updateMany, delete) - I'll see if I can dig out some documentation for you to use. Basically, it allows you to store some data against a uuid / user and then use that data as you see fit. Now, because of how this is currently being used, it was more aimed at storing preferences, though you can store large data structures. The upshot of this, is that you should not put any confidential information into here, as others may be able to get to it.

The rules around who can see what goes as follows. If you use a widget uuid, then only people who have contribute rights the site the widget is on can create data-store entries for that widget. To get data-store entries for a widet uuid that is on a site, you only need view rights to that site.

When it comes to editing data-store entries, you can always edit ones that you own (created) but to edit other peoples you need the correct roles enabled. (Unless the permissions you have on the site have changed to deny you access)

So, what does this all mean? It means you can store data, but at the moment it's insecure. I do have a plan to introduce a 'private' flag, which will allow you to lock down data on a per-user basis, but we haven't needed that yet, so it's not been added.

Using the datastore I think it should be possible to create a message system or a voting system, along with other things. In future, if the private flag is added, then it would expand the possibilities.

Hope this helps.

 

/**
     * @api {get} /datastore/get Get Datastore entries
     * @apiVersion 2.0.0
     * @apiName get
     * @apiGroup datastore
     *
     * @apiDescription Allows you to get datastore entries saved against users / target uuids. If the target_uuid is a widget on a site, then only people who have view rights or higher can get datastore entries.
     *
     * @apiParam {String} target_uuid the uuid against which you wish to get  data (e.g. for a widget this.options.content_uuid)
     * @apiParam {String} data the data you are looking for
     * @apiParam {String} user_uuid the uuid of the user that this data is associated with (defaults to current user if this param is not passed)
     * @apiParam {String} alias the alias for this data, e.g. student.locker_number
     *
     * @apiSuccessExample Success-Response:
     *
     *    {
     *      "status": "ok",
     *      "response": {
     *      "uuid": "3AAA219B200C62F048936FD4E58368084607079CA9DD69C1",
     *      "target_uuid": "36712DA5200286BDD0DECF4D1ABEE602B1A4C0ACF0987992",
     *      "user_uuid": "332B044A2000570E940A2FEB71F4F0011971AB7CA10B3032",
     *      "alias": "student.locker_number",
     *      "data": "A4578B",
     *      "created_by": "332B044A2000570E940A2FEB71F4F0011971AB7CA10B3032",
     *      "created_on": 1512127146,
     *      "updated_on": null,
     *      "updated_by": null
     *   }
     *
     */
/**
     * @api {post} /datastore/create Create Datastore entries
     * @apiVersion 2.0.0
     * @apiName create
     * @apiGroup datastore
     *
     * @apiDescription Allows you to create datastore entries saved against users / target uuids If the target_uuid is a widget on a site, then only people who have contribute rights or higher can create datastore entries.
     *
     * @apiParam {String} target_uuid the uuid against which you wish to associate the data (e.g. for a widget this.options.content_uuid)
     * @apiParam {String} data the data you want to store
     * @apiParam {String} user_uuid the uuid of the user that this data is associated with (defaults to current user if this param is not passed)
     * @apiParam {String} alias the alias for this data, this can be anything you want, and is to help you differentiate the data. For example: 'student.locker_number, student.random_data' max (255 chars)
     *
     * @apiSuccessExample Success-Response:
     *
     *    {
     *      "status": "ok",
     *      "response": {
     *      "uuid": "3AAA219B200C62F048936FD4E58368084607079CA9DD69C1",
     *      "target_uuid": "36712DA5200286BDD0DECF4D1ABEE602B1A4C0ACF0987992",
     *      "user_uuid": "332B044A2000570E940A2FEB71F4F0011971AB7CA10B3032",
     *      "alias": "student.locker_number",
     *      "data": "A4578B",
     *      "created_by": "332B044A2000570E940A2FEB71F4F0011971AB7CA10B3032",
     *      "created_on": 1512127146,
     *      "updated_on": null,
     *      "updated_by": null
     *   }
     *
     */
 /**
     * @api {post} /datastore/update Update Datastore entries
     * @apiVersion 2.0.0
     * @apiName update
     * @apiGroup datastore
     *
     * @apiDescription Allows you to update datastore entries saved against users / target uuids. If the target_uuid is a widget on a site, then only people who have contribute rights or higher can update datastore entries.
     *
     * @apiParam {string} The uuid of the entry you wish to update <strong>(Required)</strong>
     * @apiParam {String} target_uuid the uuid against which you wish to associate the data (e.g. for a widget this.options.content_uuid)
     * @apiParam {String} data the data you want to store
     * @apiParam {String} user_uuid the uuid of the user that this data is associated with (defaults to current user if this param is not passed)
     * @apiParam {String} alias the alias for this data, this can be anything you want, and is to help you differentiate the data. For example: 'student.locker_number, student.random_data' max (255 chars)
     *
     * @apiSuccessExample Success-Response:
     *
     *    {
     *      "status": "ok",
     *      "response": {
     *      "uuid": "3AAA219B200C62F048936FD4E58368084607079CA9DD69C1",
     *      "target_uuid": "36712DA5200286BDD0DECF4D1ABEE602B1A4C0ACF0987992",
     *      "user_uuid": "332B044A2000570E940A2FEB71F4F0011971AB7CA10B3032",
     *      "alias": "student.locker_number",
     *      "data": "A4578B",
     *      "created_by": "332B044A2000570E940A2FEB71F4F0011971AB7CA10B3032",
     *      "created_on": 1512127146,
     *      "updated_on": null,
     *      "updated_by": null
     *   }
     *
     */

    /**
     * @api {post} /datastore/delete delete Datastore entries
     * @apiVersion 2.0.0
     * @apiName delete
     * @apiGroup datastore
     *
     * @apiDescription Allows you to delete datastore entries. Data store entries are found based on the params you send, and delete if you have the correct permissions.
     *
     * @apiParam {string} The uuid of the entry you wish to delete
     * @apiParam {String} target_uuid <strong>optional</strong> the uuid against which you wish to associate the data (e.g. for a widget this.options.content_uuid)
     * @apiParam {String} data the data you want to delete <strong>optional</strong>
     * @apiParam {String} user_uuid the uuid of the user that this data is associated with (defaults to current user if this param is not passed) <strong>optional</strong>
     * @apiParam {String} alias the alias for this data <strong>optional</strong>
     *
     * @apiSuccessExample Success-Response:
     *
     *    {
     *      "status": "ok",
     *      "response": {
     *          true
     *   }
     *
     */

 

  • Like 1
Link to comment
Share on other sites

This is brilliant and believe me I will attempt to make good use of this, but its not what I had in mind.

Lets take a real world example. Fog 3 had room controls and it was brilliant (then a ms update broke it).

I want to re-implement this feature into frogos and this is how I would go about this:

  1. Call Frog and plead/beg for them to install a proxy package for centOS.
    1. Back up plan, write my own in php or js.
  2. Direct student traffic though the proxies port.
  3. Create a frog app for the new proxy, with a php back end.
  4. Create a mysql db and bit of scripting magic to implement proxy rules based on the db.
    1. The data base would need to consist of a table for each room and machine.
    2. Need to know what member of staff is controlling the room.
  5. Create a control panel for teachers and admin in the newly created frog app using js.
    1. I would need to safely query the db from js via calling a function on the apps back end.
    2. I would also need to send data back when a teacher changes a setting.
  6. Test it till it breaks and fix it.
  7. repeat 6 & 7 again.
  8. Call Frog and show them.

This is one simple example, I am not saying you guys should allow us to go about installing Linux packages on the box. My point being this, if we had the ability to write some back end php for a frog app. Then maybe the community can work with frog, on some of frogs next big features, just look at the work we are all-ready doing. @Graham Quince This is the reason why I love frog and wan't to get into doing more with it. So why is frog code on the back burner?

Anyway, that's just an example and a quick plea. i doubt i'm going to attempt a new room controls.

 

 

Edited by Chris Goluch
Link to comment
Share on other sites

On 28/06/2018 at 19:51, Chris Goluch said:

@Graham Quince This is the reason why I love frog and wan't to get into doing more with it. So why is frog code on the back burner?

Hi Chris,

It is the usual reason I'm afraid - there's so much we want to do, that schools want us to do and only finite resources.  We'll get there.

Graham

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...