The description is the same for SEARCH_SOURCE_DISPLAY_PARAM and SEARCH_SOURCE_PARAM. Can you clarify the difference between these values?

I changed it, is it better now?

Yes, that makes more sense... though I wonder if it would be better to simply look up the display name of the source in the alphabrowse origin class, instead of passing it visibly through the URL. I realize this would be non-trivial (we'd need to inject the config through the factory, and perhaps create a trait or helper class to make the existing getTypes method available in more places than just the AlphaBrowseController). Do you think it might be worth the effort in order to make things slightly more seamless? Or is that too much work/complexity?

I wanted to do it at first after, like you, realizing it's heavy, however I'm happy to do it if you feel it would be good
What we might do, if it makes sense for you, it's to make it whenever we implement another origin needing a code improvement

Yes, I could live with performing this simplification as a future follow-up, after getting the basic system in place.

In the meantime, I've just pushed up a small commit to make slight adjustments to the comment on the display property.

I'll also follow up with @EreMaijala and see if he has any further thoughts before we move forward with this.

@rominail, just a note to say that this hasn't been forgotten about. @EreMaijala and I had a long discussion about this PR and would like to find a way to achieve the same effect with fewer query parameters and less explicit plumbing in the controllers, to keep things simpler and more decoupled. I think there are at least two possible alternative approaches that might be improvements:

1.) There has been a long-standing ticket (VUFIND-1652) to create a mechanism for persisting session-specific data in the database. We could probably use this to persist a serialized SearchOrigin object, and then we could pass a simple identifier in the query and use it to retrieve the full object from the database. I think this would make things look a lot cleaner, though it requires us to build that mechanism before we could implement it.

2.) There's also a possibility of refactoring code so that browsing is treated as a subset of searching instead of a distinct activity. We could then use the existing "sid" to keep track of browse activities, and add the ability to chain searches together for breadcrumb purposes. This would be a totally different solution to the problem and would require a lot of code changes, but it holds some theoretical appeal at least.

Unfortunately, both of these theoretical approaches require some groundwork would prevent this PR to get finished right away -- so the next question is whether you're in a hurry to get this resolved for your local needs. If you don't mind waiting, I'd be interested to hear if you have preferences, and then we can start working on strategy to get the necessary prerequisites in place. If you're in a hurry, though, maybe we can find a different compromise. :-)

On our sides we are in no rush, the modification has already been made on our instance
I don't really have strong feeling
Regarding the sessions and / or storing anything in DB, in case of a bot crawling (not following rules) (which happens regularly) it loads the servers significantly

Thanks, @rominail -- since you're not in a hurry and some more thought is needed here, I've moved this to the 11.0 milestone for now.

Any more thoughts? What should I do?

I don't think you need to take any action right now. I'm hoping that @EreMaijala will have some more suggestions eventually, but since we're currently more focused on finishing up release 10.1, this will probably be on hold for a bit until work on 11.0 intensifies.