Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Localfiles #42

Merged
merged 15 commits into from Dec 15, 2016

Conversation

Projects
None yet
8 participants
@copongcopong
Copy link
Contributor

copongcopong commented Nov 13, 2016

Proof of concept for having Jasonette files (*.json) inside a folder (/localfiles) within the app;

local://demo.json will be the url path;

local:// is being replaced with the exact path of the folder /localfiles and loaded by Jason.drawViewFromJason

@gliechtenstein

This comment has been minimized.

Copy link
Contributor

gliechtenstein commented Nov 17, 2016

@copongcopong I read through both versions of your code (the web server version and this one), and have thought about it last couple of days. I think each has pros and cons:

  1. Setting up a web server: It might be too heavy (may eat up a lot of resources), we will need to investigate on this.
  2. Open the file directly from the bundle: This is much lighter but after thinking about this for a bit I can think of some challenges.

Let's say we are truly offline. And we want to serve everything locally from the bundle. In this case, even the example you added wouldn't work, since the images are still being loaded remotely (example) To make this work, I can imagine adding all the images to the project and maybe refer to them http://local/avatar1.png, http://local/avatar2.png etc. In this case, the challenge would be to make sure there's no collision in the image file names.

Also, you wouldn't be able to make $network.request action calls either (since it's offline).

I still haven't given up on the approach#1 (which you first came up with) and still think it can have some exciting usage, but I'm not so familiar with how much load having a web server introduces. For example, we wouldn't be able to add the web server into the core module if it's running always and it drains the battery or affects rest of the performance. I really have no idea yet because I haven't used this in my apps before. So I think we will need to investigate.

As for approach #2, what are your thoughts? Do you still think (after having used Jasonette for a bit) local JSON is useful, even with all these limitations? Also, I'm curious, was there a reason you switched from the web server approach to this approach? Was there a performance problem?

@copongcopong

This comment has been minimized.

Copy link
Contributor Author

copongcopong commented Nov 17, 2016

@gliechtenstein
For WebServer approach, the good thing about it is images and any other files we want the app to access can be handled without really adjusting most part of the JASON codebase.

For the localfile-json file approach, my prototype appears to be limited to only .json files and will not cover images, unless images are URI-encoded inside the .json;

Since you plan to also support images for local-path-type of access, i'd go with approach 2;

For my personal simple testing/toying around with this 2 approach, localfile-json approach appears to be faster than the webserver prototype;

@thedumbtechguy

This comment has been minimized.

Copy link

thedumbtechguy commented Nov 17, 2016

I think even for images, you stick with the local:// protocol.
Using http://local can lead to problems.

On Thu, Nov 17, 2016 at 2:44 AM, Earl Celis notifications@github.com
wrote:

@gliechtenstein https://github.com/gliechtenstein
For WebServer approach, the good thing about it is images and any other
files we want the app to access can be handled without really adjusting
most part of the JASON codebase.

For the localfile-json file approach, my prototype appears to be limited
to only .json files and will not cover images, unless images are
URI-encoded inside the .json;

Since you plan to also support images for local-path-type of access, i'd
go with approach 2;

For my personal simple testing/toying around with this 2 approach,
localfile-json approach appears to be faster than the webserver prototype;


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#42 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA4XZRqTVwM_bzMM4dhqKnMGyTw-ySgmks5q-7-rgaJpZM4KwojG
.

Regards,
Stefan Froelich.

@gliechtenstein

This comment has been minimized.

Copy link
Contributor

gliechtenstein commented Nov 19, 2016

I think we're almost good to go with this. Two things:

  1. I literally just had this idea just now, how about we use file:// url scheme instead of local?
  2. Just to be consistent with rest of the directory structure, maybe it's a good idea to place the local files under assets? I'm thinking maybe creating a json folder under assets and placing all json files there. (And probably refer to them as something like file://json/hello.json) Basically this way we can access everything that's inside assets folder via file:// url scheme.

screen shot 2016-11-19 at 2 48 09 pm

I think once we can make decisions on these things we can go ahead and merge it in. What do you think?

@thomasbarwanitz

This comment has been minimized.

Copy link

thomasbarwanitz commented Nov 19, 2016

Nice

@superboonie

This comment has been minimized.

Copy link

superboonie commented Nov 19, 2016

@gliechtenstein One small thing - I suggest that we name the folder based on its purpose/nature, rather than its type. For example, you wouldn't call Jpg instead of images or Wav instead of Sound. It's easier to understand and more scalable.

@gliechtenstein

This comment has been minimized.

Copy link
Contributor

gliechtenstein commented Nov 21, 2016

@superboonie I think we can leave the naming up to users? My suggestion was use the Assets folder as root, so users can create whatever folder they want under the the Assets folder (or maybe even just put the files right at the Assets folder level).

But your point still makes sense. I think it's good to have a default folder so that people can organize files better, otherwise people will just end up putting them under Assets folder. Maybe "data" or "document"? Please feel free to make a suggestion.

Btw @copongcopong would you like to take a stab at an updated pull request so it can be merged in? If you're not sure you can just let me know here or via slack. Let's move ahead! :)

@superboonie

This comment has been minimized.

Copy link

superboonie commented Nov 23, 2016

@gliechtenstein Is the JSON mainly for UI rendering? If so maybe calling it UI will be suitable. Data is good but may be too generic in conveying what purpose it serves.

@gliechtenstein

This comment has been minimized.

Copy link
Contributor

gliechtenstein commented Nov 23, 2016

@superboonie I think for this particular use case it's just for view, but it's better to make it generic going forward, so for example you could do something like this:

{
  "$jason": {
    "head": {
      "actions": {
        "$load": {
          "type": "$file.open",
          "options": {
            "url": "file://document/db.json"
          },
          "success": {
            "type": "$render"
          }
        }
      }
    }
  }
}

In that sense I think document makes most sense so far, since it's a term that's both used to describe views (think html document) and models (think mongodb document).

That said, this is just a side discussion. For this specific feature, all we need is an ability to set the main url for a view, which this pull request already does.

@copongcopong

This comment has been minimized.

Copy link
Contributor Author

copongcopong commented Nov 24, 2016

UPDATES

  1. Uses the Assets Folder (Core/Assets)
  2. declaration is now via file://
  3. Error Toast appear if Jason file is not found
@rborn

This comment has been minimized.

Copy link

rborn commented Dec 7, 2016

Can this be merged? 😄

@gliechtenstein

This comment has been minimized.

Copy link
Contributor

gliechtenstein commented Dec 7, 2016

Sorry guys, I've been meaning to merge this, but been focused on Android for the last couple of weeks so didn't want to introduce any complication on the iOS side. I've already discussed with @copongcopong and the code is pretty much ready to go, so will try to get it merged soon. Will keep you posted!

@gliechtenstein gliechtenstein merged commit 438871f into Jasonette:develop Dec 15, 2016

@gliechtenstein

This comment has been minimized.

Copy link
Contributor

gliechtenstein commented Dec 15, 2016

Ok finally got around to merging this.

I was trying to cherrypick the commits and something went wrong along the way so it got kind of hairy but managed to get it working now.

Oh by the way @copongcopong I also fixed the problem with the http:// automatically getting attached in front of file:// (commit here) so the exception handling logic is not necessary anymore, so i removed that part as well.

TLDR;
To get this to work, all you need to do is:

  1. place a JSON file anywhere under file:// folder
  2. Refer to it from settings.plist, for example file://hello.json (Note that XCode projects don't maintain file/folder hierarchy so you can't do stuff like file://documents/hello.json. It's always file:// followed by the filename.

screen shot 2016-12-15 at 11 07 31 am

Thanks for the pull request and sorry it took so long!

@lukeramsden

This comment has been minimized.

Copy link
Contributor

lukeramsden commented Dec 17, 2016

@gliechtenstein the one thing putting me off Jasonette was no offline files. But with this addition, I'm considering rewriting my current project entirely with Jasonnete! (from NativeScript). Great work you guys are doing +1

@gliechtenstein gliechtenstein referenced this pull request Jan 3, 2017

Closed

Localweb #39

@gliechtenstein gliechtenstein referenced this pull request Jan 15, 2017

Closed

Document Local JSON #34

@mcapodici

This comment has been minimized.

Copy link

mcapodici commented Mar 28, 2017

Hi. Is the file:// local resource feature available on Android too?

@gliechtenstein

This comment has been minimized.

Copy link
Contributor

gliechtenstein commented Mar 28, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.