Base for new study page

[squirrelo]

This adds in the base HTML and index handler for the study pages, and a single example of the AJAX-call-based updates done on the page. The idea is that we load the minimal information to show the first page, and then lazy load each bit of information needed as it is called for, so we save a lot of time and database calls that would be duplicated if we just reloaded the page for every link click. It also means we no longer need to load all information for all files when the page is accessed.

[antgonza]

If optional and not present this is going to fail.

[squirrelo]

The wording is bad, but I think it's supposed to mean it could be part of the main info, but we thought no. I'll reword, since really it's removed because it's redundant to the study id already stored in the object.

[antgonza]

Some comments but good start. I guess the idea is to merge this once comments are addressed + other reviewer and start building from there, right?

[squirrelo]

Exactly. This framework allows the rest of things to be done in parallel. The only thing that may get merge conflicts is adding the ajax functions to the top of the main study html page.

[antgonza]

👍

[squirrelo]

Tests are expected to fail since the study description page has been removed and replaced by this skeleton, which is missing most of the functionality at this moment.

[ElDeveloper]

This is missing a space between the description and the Returns header.

[squirrelo]

Done

[ElDeveloper]

Seems like this could return None, should this be checking and instead returning an empty list? Otherwise it would probably be worth updating the docstring. My preference would be to return an empty list, not sure what others think about that.

[squirrelo]

This will return an empty list if nothing is in the SQL.

[ElDeveloper]

Got it, then I'm confused what you are checking for in line 89 of api_proxy.py, maybe that's unnecessary then?

[squirrelo]

ah, yes that's a redundant check.

[ElDeveloper]

Only owners of the study should see "all" the information, right, this should be filtered for things the user can see, which are presumably only "public" artifacts right?

[squirrelo]

I'm leveraging the API on this one, since this design keeps with the current assumption that the API call object only returns what information is viewable by the user.

[ElDeveloper]

OK, got it, that makes perfect sense, we should really keep an eye
opened for this as otherwise it will lead to a rather strange-looking
UI.

On (Dec-14-15|12:50), Joshua Shorenstein wrote:

• Upload Files
  
• Edit Study Information
  
• Delete Study

• Data Types

•  <div class="panel panel-default">
  

•  {% for dt in prep_info %}
  

•  {% set cleaned_dt = dt.replace(' ', '_') %}
  

•    <div class="panel-heading" role="tab" id="heading{{cleaned_dt}}">
  

•      <h4 class="panel-title">
  

•        <a role="button" data-toggle="collapse" data-parent="#accordion" href="#collapse{{cleaned_dt}}" aria-expanded="true" aria-controls="collapse{{cleaned_dt}}">{{dt}}</a>
  

•      </h4>
  

•    </div>
  

•    {% end %}
  

•    {% for prep in prep_info[dt] %}
  

I'm leveraging the API on this one, since this design keeps with the current assumption that the API call object only returns what information is viewable by the user.

---

Reply to this email directly or view it on GitHub:
https://github.com/biocore/qiita/pull/1571/files#r47555626

[squirrelo]

Comments addressed

[ElDeveloper]

Thanks @squirrelo