|
I have a quick question about a web tool I develop for. Here is an example page on my development site for reference: http://gn2-zach.genenetwork.org/show_trait?trait_id=1427571_at&dataset=HC_M2_0606_P This page (the trait page) is a hub of sorts, where the user might want to run a variety of tools (primarily correlations/mapping). Before doing so, they can change/remove samples (from the list at the bottom of the page) or change other settings specific to the tool in question. My question is whether there is any reasonable alternative to having target="_blank" in the form element. I know that it is usually preferred to avoid target="_blank", but it seems like it would be extremely irritating for the user if they have to hit back and redo all of their options/changes to samples after running a tool. Ideally I would be able to treat the submit buttons like hyperlinks, where the user can just right-click and choose if they want to open in a new tab/window, but I can't think of any way to do that with a form submission like this (using GET seems like it would be awkward here, given the potentially huge amount of parameters since it needs to pass all the sample data, which might be hundreds/thousands of individuals). Is there any way for me to give the user the ability to optionally open in a new tab/window in this situation? And if not, is this a situation where it is acceptable to use target="_blank"?
|
#
¿
May 2, 2016 18:55
|
|
|
|
| # ¿ May 3, 2024 07:55 |
|
|
This is a kind of broad question, but I have a problem where I need to load a large amount of data into a table (50,000+ rows) and I'm not sure if the solution I have in mind makes sense. Currently the data is passed into the template as JSON and loaded into DataTables (which uses the Scroller plug-in), but this is obviously not really viable when there's a ton of data. My thinking is that I can store the JSON in a file and then create an endpoint (I'm using Python Flask) that takes the filename (or some ID associated with it) as a parameter and returns the JSON (that was stored in the file), and then DataTables loads the data from an AJAX call to that. Does this make sense? (The reason I'm not considering server-side processing for this table is that it isn't practical without largely redoing the way the page in question works.)
|
|
#
¿
Dec 1, 2020 20:20
|
|
|
Ruggan posted:If you are creating 50k HTML table rows from data you're going to have a bad time. Your user will need to wait for the template to load, which will be huge. The user isn't going to be able to effectively see/use all the rows anyway so don't do that. It won't be that many HTML rows; I'm using DataTables with the Scroller plug-in that loads rows on demand as you scroll. I think Scroller essentially accomplishes the same thing paging would as far as displaying the actual html goes. Pagination isn't preferred in this situation (my boss doesn't like it, lol). But (as you mentioned) I think it would still end up needing to download all the data, even if it's not directly loading it into the template (which is what it was doing before, with results truncated to allow for this). I think it largely depends upon how exactly DataTables deals with AJAX-sourced data with the deferred loading option enabled (I don't know if it will immediately load some of the rows or if it will have to download all of the data first). I've looked into something like streaming data with Flask, but I'm not sure how that would work with DataTables. Tomorrow I'll get it working with Scroller and sourcing the data from an AJAX call, so I'll at least know how that performs. It's not the end of the world if it's a little slow (only a small fraction of results will be really large - the context in this case is displaying genome mapping results, so length corresponds to number of markers in the genotype file). Splitting the results up into chunks is possible, but I'm not sure how to feed that to a single DataTables table. It might actually be possible to use server-side processing somehow (without rewriting a bunch of stuff); a coworker seemed to think it wasn't easily doable, but it seems to me like it should be doable since it just needs to refer to an existing JSON file for the data.
|
|
#
¿
Dec 2, 2020 08:51
|
|
|
There's a certain "bug" that's been confusing me for a while, so I figured I'd run it by this thread and see if anyone has encountered anything similar (it seems like the sort of issue that is difficult to Google, since attempts to search for it bring up many unrelated topics). There's this one POST form on my website that submits a request to an end-point that can receive both GET and POST requests. It either submits a bunch of form inputs (with the POST) or just a single hash that is used to fetch the cached inputs from Redis (with the GET - this is so users can link directly to results). This works correctly for most users, with the unfortunate exception of my boss. For some reason, the first time he submits the form it is wrongly submitted as GET (and throws an error as a result, since it's basically treated as a GET request with zero inputs). After that, it is correctly submitted as POST. Other relevant information: - The page with the form contains an input indicating the "final destination" endpoint. It first submits to a loading page, which then uses some JS to submit to said endpoint. I think this is where the problem occurs (but it's hard to test since I can't reproduce it). - I'm pretty sure this issue was introduced when I changed the endpoint in question to allow both GET and POST requests. If absolutely necessary I could always use two separate endpoints, but I feel like that shouldn't be necessary (and it currently works for seemingly everyone but my boss, which makes me think there's some sort of issue involving the specific browser* or an ad/content-blocker, though the website should obviously still work despite that). - I have absolutely zero clue why it works for him after the first attempt. Basically, the first time he runs the function on a specific trait, it does the bad GET submission and throws an error. But every subsequent time, it correctly submits as POST and runs normally. * my boss uses Safari, but I don't encounter the issue if I use Safari on my mac laptop - as far as I'm aware my boss is literally the only person who has encountered this problem, but unfortunately he's also "the most important user" for obvious reasons lol edit: I made a change that I think will fix the issue (at least without any more significant changes). Still waiting on my boss to test (since he's the only one who can actually confirm whether it works). I basically just changed the "/the_function" endpoint to only accept POST again, and instead made the other "linkable" endpoint be structured like "/the_function/<hash>" instead of "/the_function?hash=<hash>". I still don't know what was causing the "false" GET requests, but I think this will probably prevent the issue since I'm 99% sure it was introduced by allowing both GET and POST requests at that endpoint. Ytlaya fucked around with this message at 19:38 on Jul 5, 2023 |
|
#
¿
Jul 5, 2023 17:58
|
|
|
We have a (POST) form with target="_blank" on our website to get the results to open in a new window/tab, but apparently this doesn't work in the Orion web browser (it does work in other major browsers). It seemingly just submits the form with no inputs. Are there any alternatives to this (or possibly a setting in the Orion browser that could cause it)? My boss is insistent that the "open in a new tab/window by default" behavior remain, and understandably so. It's an analysis website, and the page in question is one where you can run a variety of analysis tools on editable data, so users don't want to have to keep hitting back, or manually telling it to open in a new tab. The only possibly explanation for this I could find was something related to "XHTML Strict" not allowing target="_blank" but I don't know if that's the actual reason.
|
|
#
¿
Apr 19, 2024 16:44
|
|
|
|
| # ¿ May 3, 2024 07:55 |
|
|
Ytlaya posted:We have a (POST) form with target="_blank" on our website to get the results to open in a new window/tab, but apparently this doesn't work in the Orion web browser (it does work in other major browsers). It seemingly just submits the form with no inputs. Are there any alternatives to this (or possibly a setting in the Orion browser that could cause it)?
|
|
#
¿
Apr 19, 2024 16:45
|
|