zotero / web-library Goto Github PK

use https://github.com/devote/HTML5-History-API in place of History.js as it uses the actual html5 history api instead of a modified version, and has slightly less insanity built into it.

May have to deal with browser inconsistencies for when popstate is fired ourselves.

@tnajdek the images folder can’t be reached from the served directory.

Currently being sorted inside javascript which places multi-byte chars after z

solutions:

1. Request tags from api sequentially and keep them in that order.
2. browsers may eventually do a better job with localeComparison for us.
3. indexed DB may or may not sort them the way we actually want.

Interface for selecting visible columns in the item list (#56). Currently we're using a pop up for this in the web-library and a menupopup in the client.

I would like to have a shared set of icons for both Zotero and Tropy.

I guess it makes sense to implement them in a similar manner: all icons will be inline SVGs, in order to keep the components clean we decided to put them in an icon component themselves for Topy (have a look at the repository in components/icons.js). The icon component does not need any logic.

The rationale behind this approach is the ability to control the icons with CSS. Every SVG (or at least where needed) will contain a 'linear' and a 'block' version, which can be selected and colorized (or even animated) then.

https://forums.zotero.org/discussion/56920/adding-publisher-column-does-not-show-institution-field/#Comment_249557

Not sure if there's a way to make it fail loudly. I assume the error is being swallowed up by either babel or gulp.

Since we're converting the library so it doesn't depend on Bootstrap, I'm going to suggest few additional tweaks as part of this work:

1. Add Redux as a global state container
2. Use Container and Presentation components for separation (1, 2, 3)
3. Remove dependency on jQuery
4. Expose all components (aka widgets) under Zotero.ui namespace
5. Expose static init() methods on components for quick DOM mounting
6. Avoid any side-effects of including the library. e.g. avoid a situitation where just including the library would inject/replace component (aka widget) into the DOM based on its attribute/id.
7. Avoid using ids (for component styling or otherwise) to allow multiple instances of the same component on a page.
8. Potentially: split of non-core functionality/components into separate library/libraries

I've done some initial work in a branch called redux, any thoughts and comments welcome.

Give tags cached in sessionStorage a reasonable expiration until we can reasonably poll the api for changes.

Currently a single item is selected if present in the url (and thus displayed in the item details pane) but this is undesirable for layouts that keep both an item list and item details visible.

This breaks attachment uploads (among other things less significantly) as currently implemented. Need to parse the new style of responses to get the item key for further requests.

Simple search functionality needs to be ported to the new library. We could use instant search to match client's behavior (as opposed to press enter to search in current version).

The following features are not yet ported:

• Creators field
• Editable fields
• Item type field
• Notes field (?)

https://forums.zotero.org/discussion/30295/strange-autocomplete-behavior-on-web-access-to-my-library/#Item_0

Currently they are exposed only with the control panel which hides if the library is not editable.
They also depend on items being selected, so item checkboxes may need to always be visible.

There should be a target on the home domain to download/view Zotero files from. We don't want to offer downloads of snapshot zips until they are in a more reasonable format so viewing is essential and framing is still desirable. Pointing to z.org would require login/access in that context which we don't want.

http://forums.zotero.org/discussion/25993/how-to-have-real-name-instead-of-username-displayed-wherever-possible/

http://forums.zotero.org/discussion/24713/usernames-vs-displayed-names/

And potentially a user pref to opt out of such behaviour, or just use the search engine indexing preference as a proxy.

http://forums.zotero.org/discussion/8471/added-by-usernames-rather-than-real-names/

https://forums.zotero.org/discussion/29214/provide-method-to-produce-intext-citation

• Clone selected items
• allow user to select from other libraries they have access to
• check existing relations on selected items to make sure they're not already in the target libraries
• add appropriate relations to both new and old items to reflect that they're the same
• write new copies of items to selected libraries
• update old items with new relations

On production zotero.org
Other sprite icons apparently fine.

As already concluded it does not make any sense to blindly detect touch devices, the user has to be in control of the information density.

Nevertheless a best guess seems feasible, therefore a modernizr test detecting touchevents could already be implemented.

As the user should be able to toggle density modes in the settings, I will not use modernizr’s touchevents class directly but rather our own touch class~~, either~~ on the htmlor bodyelement.

Our class would reflect the modernizr test unless the user decides against it.

We don’t have the settings dropdown yet, but it will be available soon.

We should allow emptying the entire trash with a single operation from the web library.

• get the full list of items in the trash (/items/trash?format=keys)
• confirm the user wants to permanently delete X items (?)
• perform the multiple DELETE requests to permanently delete the items (probably in series, rather than parallel)
• report the progress of the operation as it goes

Parts of this could potentially be re-used in other contexts, such as reporting progress for multi-request operations (bulk edit?)

Emptying the trash is easily the most requested such option, but we could also potentially apply other operations to all items in a view (rather than just the N items currently displayed) such as moving to a collection or tagging, but that involves harder UI questions.

@tnajdek one thing that came to my mind when I had a look at the editable: during the update a spinner might not be the best solution everywhere – e.g. dropbox makes use of status texts when you rename a directory.

I think I would prefer the text approach to a spinner for editing small chunks of texts. So maybe we could extend our feedback repertoire?

Talking about editable, could we even have 'optimistic updates' and just let the user know if something goes wrong?

Currently, web library offers a dialog to move an item to a collection. We need to port this feature though we might come up with another solution (e.g. using drag n drop on desktop).

The initiation of RTEs on pages is inconsistent in various places, especially between text fields that present in the DOM when JS loads and fields that are rendered from javascript, possibly in multiple steps. Making it all happen in a single standard way will make it much more testable and reliable as JS app pages change.

Eventually may be able to do patches within the browser, but until then allowing a full upload to replace an existing attachment is acceptable.

User specific preferences such as display columns and default sort order should be persisted locally. Currently depends on being logged into a Zotero account.

In the Instructions, the very first point is "Clone git repository into target web directory". Unless I am doing something wrong, the git clone command does not include libzotero in the library folder.
That should probably be explained and suggest a second clone for that folder

S3 CORS is only currently allowed for zotero.org, so response status codes are missing. Third parties can still upload directly to s3, but will not be aware of a failure. We could proxy file uploads like we do other requests, but that would limit file size to the php install's upload limit.

• Resizable
• Editable (?)
• Sortable
• Draggable
• Icons
• Tabs
• Toolbars

… (TBD)

I think the only thing preventing this is not wanting to overwhelm users with options for styles.
An auto-completing text input that has precedence over the select might be fine.

Even when loaded and rendered by JS.

• js templates throw errors
• navs are broken in multiple interesting ways

zotero.org static rendering depends heavily on Zend framework and has several dependencies on the underlying site install which shouldn't be required.

This will require access to a running translation server, but other than that it should be straightforward. Direct requests to a translation server probably belongs in libZotero. Other than that this is just a bit of UI and glue.

https://forums.zotero.org/discussion/55467

Some upload but do not get confirmation to exit dialog (firefox mobile android 4.2)
Some are simply not capable and should not offer the option (mobile safari < 6?)
Some claim they are capable but freeze when attempted (chrome for android 4.2).

@tnajdek i know that the web library, especially its redux incarnation, still is at the very beginning and therefore not every minor issue i come across while working on the interface can or should be handled right away (and of some issues you might be aware anyware). With that said i will probably open some issues here in order to keep track of the them in the first place.

When a selection on a collection is made, the ItemList’s layout does not show up until the items are fetched. For a more stable experience it would be preferable to show the table header and the striped item-list-body right away, placing the spinner inside the item-list-body until the item-list shows up (so only the item-list would be blocked while the items are loaded).

Hi,
Does this support web-dav download/upload?

When requests are always going through a php proxy page, that page can add the api key to requests so it is not exposed on the page.

Reminder: If IE9 has to be supported, a fallback for repeating css gradients has to be provided.

The following features are not yet ported/implemented:

• Dynamic columns
• Select multiple
• Icons
• Sorting
• Pagination / "infinite" scrolling