On Mar 11, 2013, at 2:16 PM, Stefan Matheis <matheis.ste...@gmail.com> wrote:
> > On Monday, March 11, 2013 at 8:27 PM, Mark Bennett wrote: >> One benefit of this is that, if we ever need to change the implementation >> for the full form URLs, the short ones could be made to still work (redirect >> to the new form), and therefore links in documentation, online, etc wouldn't >> needed as much editing. >> >> [..] >> >> So, thoughts on shortcut URLs? > I'm actually a bit "yes, why not" Yah! Ignore rest of sentence!!! ;-) > .. but i'm not yet completely sold. i mean, the point with the documentation > is fine .. but that's it, more or less, isn't it? Also "muscle memory" for folks who use Solr all the time. And videos, etc. Short entry URLs help everybody. > > If we try to promote those urls as well in the UI itself I wasn't specifically lobbying for that. I'm fine to have the very first short URL go to the long one and then be done with it. My theory being once you're in the UI then it's not as big of a deal. > (otherwise, my guess would be that people don't really remember them) you > have to deal with two urls .. the current one you have in your browser and > the other one which would be titled as .. "permalink", kind of? A simple rule could be "short URLs always redirect to the long / correct URLL" (which may change version to version) And use a 301 or 302, whatever the web gods think is correct. > > On Monday, March 11, 2013 at 8:27 PM, Mark Bennett wrote: >> Ideally, if running in cloud mode, / would take you to an admin that shows >> that, but there also needs to be links back to admin for the node you've >> connected to. > > > I'm not sure if i get you here? links back to which node? you mean, if you > switch from one instance to another, because you followed the links in the > cloud-graph? Few things: 1: Even when I'm looking at a cloud admin screen, that was rendered by one specific machine, so a link to *that* machine is nice. 2: Generally a link to any of the nodes listed, but there needs to be a link back to cloud view (I logged a JIRA on that) 3: For extra credit, it'd be nice to have a link back to the machine I started at, or even some type of breadcrumb thing?, but not sure there's a compelling reason to do that. > > Stefan > > > On Monday, March 11, 2013 at 8:27 PM, Mark Bennett wrote: > >> Stefan, >> >> Thanks for the info, and congrats on your new gig. >> >> I figured there were logical explanations for such all of it, sounds like >> there is. And generally once you're in the UI, there's not problem with >> somewhat odd URLs. >> >> Plan B was just to allow for shorthand URLs that would redirect to the full >> URLs. >> >> / to solr admin >> >> /cloud to cloud >> >> /collectionname to that collection >> >> /search/collname to …./select, etc. >> >> One benefit of this is that, if we ever need to change the implementation >> for the full form URLs, the short ones could be made to still work (redirect >> to the new form), and therefore links in documentation, online, etc wouldn't >> needed as much editing. >> >> Ideally, if running in cloud mode, / would take you to an admin that shows >> that, but there also needs to be links back to admin for the node you've >> connected to. >> >> So, thoughts on shortcut URLs? >> >> >> On Mar 8, 2013, at 2:36 AM, Stefan Matheis <matheis.ste...@gmail.com >> (mailto:matheis.ste...@gmail.com)> wrote: >>> Hey Mark >>> >>> I'm a bit late on your issues, but after the vacation things got a little >>> busy … >>> >>> Hoss already explained a few things in his comment >>> (https://issues.apache.org/jira/browse/SOLR-4431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13596596#comment-13596596) >>> on SOLR-4431 >>> >>> I'll try to bring a few additional thoughts: It all started with SOLR-2399, >>> moving the UI to a single-page app .. avoiding the (at this time) current >>> situation having multiple sites .. each for one core, so you had multiple >>> places where you could ask solr for its information about threads .. but >>> they are never really core-related, it's kind of "meta-information" which >>> is valid for the whole instance. >>> >>> The page is using sammyjs (http://sammyjs.org/) as Framework, and therefore >>> includes the # in the url. Like hoss already explained, everything after >>> the # isn't sent to the server and can therefore directly be controlled on >>> the client-side in your browser. >>> >>> Because i don't really know which browsers users use for the UI (and it >>> seems there are at least a few IE-Users out there ;o) i tried to avoid >>> using fancy stuff which will only work in newer browsers. Having said that >>> .. in theory you can avoid those # - but therefore you have to ensure that >>> every single url which is used by the UI is correctly handled by the Server >>> (think of switching details on the plugin-site) >>> >>> Using the Tilde was a try to distinguish between stuff that is core- and >>> non-core related, otherwise (also like hoss already said) there would be a >>> conflict if the user uses (for whatever reason) a core named >>> java-properties, threads and so on. >>> >>> the "/solr" part is based on the fact, that you could install multiple >>> webapps into a servlet-container and they have to be mounted on a path. >>> that could clearly be root (/), but i guess there are reasons why does >>> wasn't used in the example package - but the UI will work anyway, because >>> the information on which path solr is running is inject in the page while >>> its initially loaded >>> >>> If i did miss some questions you'd like to know things about .. just let me >>> know :) >>> >>> Stefan >>> >>> >>> On Thursday, March 7, 2013 at 11:10 PM, Mark Bennett wrote: >>> >>>> As part of making Solr easier to use for new developers, one of the JIRA's >>>> I had filed was: >>>> >>>> SOLR-4431: Developer Curb Appeal: easier URL to get to Cloud UI >>>> https://issues.apache.org/jira/browse/SOLR-4431 >>>> >>>> I've been trying to understand why we have such odd URLs in the first >>>> place, and could they be simplified? >>>> >>>> I'm talking about URLs like: >>>> http://localhost:8983/solr/#/ >>>> http://localhost:8983/solr/#/~cores >>>> http://localhost:8983/solr/#/~cloud >>>> >>>> >>>> I'm sure there's logical reasons for all of this, but I've had trouble >>>> finding the original discussion threads on Google (terms like Solr and URL >>>> have huge match sets) >>>> >>>> I looked around Solr's web.xml (http://web.xml) file and I see some >>>> references to # and ~, but it doesn't really explain it, and there's a >>>> comment ("Remove in Solr 5.0") that applies to at least one of the >>>> mappings; I wasn't sure of the scope. >>>> >>>> Specific questions: >>>> >>>> * I assume this was discussed, maybe in JIRA? I was looking for the >>>> original threads >>>> * or, Why was this done? >>>> >>>> * Did it strike anybody as odd at that time? >>>> >>>> * Is this changing in Solr 5? If so, to what? >>>> >>>> * Or, could it be easily changed to remove "#/~" parts? (I imagine each >>>> character has it's own reason for existing) >>>> So ideally it'd be: >>>> http://localhost:8983/solr/cores >>>> http://localhost:8983/solr/cloud >>>> >>>> >>>> * If it can't be easily changed due to some architectural issue, could we >>>> add some simple redirects to the web.xml (http://web.xml) file? (Even if >>>> we did change the URLs, we'd probably want redirects to preserve the old >>>> URLs for a while) >>>> >>>> * Could we add web.xml (http://web.xml) rules to allow for Solr to be the >>>> root app? >>>> So in default Jetty: >>>> http://localhost:8983/admin >>>> http://localhost:8983/cores >>>> http://localhost:8983/cloud >>>> >>>> http://localhost:8983/search/collection1?q=... >>>> >>>> >>>> I suspect the current URL structure is there for very good reasons, and >>>> seemed like a good idea a few years ago. And I imagine somebody might have >>>> even said "nobody types in URLs, they just bookmark everything!". But >>>> developers and admins DO type in URLs all the time, and making things >>>> easier for new developers is really important. And remember #'s and ~'s if >>>> you don't use the tool every single day seems like a needless hassle. >>>> >>>> Is there some reasonable compromise here, maybe just with redirects, to >>>> make Solr URL's really simple? >>>> >>>> Thanks for any info or links or comments! >>>> Mark >>>> >>>> -- >>>> Mark Bennett / LucidWorks: Search & Big Data / mark.benn...@lucidworks.com >>>> (mailto:mark.benn...@lucidworks.com) >>>> Office: 408-898-4201 / Telecommute: 408-733-0387 / Cell: 408-829-6513 >>> >>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> (mailto:dev-unsubscr...@lucene.apache.org) >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> (mailto:dev-h...@lucene.apache.org) >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
