@hikaru I’m not quite sure what you’re going on about. As you can see in the reply that I linked to, I did in fact build that. I had no need for it personally, but did it to help out another user who asked how to do that.
The reason I said “hypothetical” is that it was merely a question… “How might I do this?” I answered by showing – in great detail – how it would be done. If you follow the instructions in my response, you can recreate exactly what I did in my demonstration.
There’s screenshots and everything.
Again, what I’m explaining in this reply is a generally applicable technique. It shows how one can create a page that – instead of getting information on a thing by sending the page the unique ID of some object (“thing” in Bubble parlance) as the path, which would be the typical way – we can instead send an arbitrary value and then, via a Search, retrieve a thing based on this the arbitrary value that is found there.
The applications for this idea are many. But they all essentially boil down to: “I want to have a dynamic page that doesn’t take a cryptic uid as its path argument. Rather, I would like to use some ‘friendly’ name or human-readable path argument that stands in for that uid. How would I do this?”
The general technique boils down to the following:
-
Create your page as you would any dynamic page. However, you would not (in general) give the page object a type. (Doing this complicates things.) As you design the page, you will not assume that the page object has a thing associated with it. You will instead grab the value of the page path yourself and take action based on that as described in 2 and 3 below.
-
On page load, retrieve the path. If the path is empty, this is just like the case when the path is empty on a “typed” page (e.g, the “Page’s thing is empty”) and should be handled similarly – either display an alert, redirect the user, etc.)
-
If the path is NOT empty, you will typically want to retrieve that value and stash it somewhere for ease of reference. It could go in a custom state located anywhere on the page. You can then have a group or groups on the page that you give types to. For the group(s) source, you Do a Search for… (the thing represented by the path argument).
-
Now inside that group you can build whatever interface you want to and have the fields and such just inherit the values from the parent group – very similar to how (in the usual page-has-a-data-type case) things on the page will more of less automatically inherit their source from “Page’s thing”.
-
Of course, you’ll probably want that “master group” not visible on page load. You would show it when your Search for the source thing has been successful and keep it hidden when not. (Conversely, the “error” version of the page – should you choose to have one – would be shown in the case of an empty path or a path that does not successfully retrieve a thing.
-
All of the above should sound kind of familiar – because it’s basically like how you would build any sort of “search” type page, or how you would have a page (for example) of type User, but then have a group inside of it that shows some other type of thing (sourced from a search), OR retrieving a thing from a URL parameter that represents some object …
The only difference is that we are “automatically” executing a search on page load. And the search term is retrieved from the path rather than from an input, from a URL parameter, or some sort of constant. (“Path” is basically the same thing as any other URL parameter, it just doesn’t have a key. Consider that:
example.com/team/justiceleague
Is just a sexier way of writing:
example.com/team?teamName=justiceleague
as long as our page logic understands that what to do with this path argument.
- Some caveats: Obviously you need to think about the path argument in a URL-friendly way. So, let’s say that you allow folks to give their Team a name that is any valid string. So as an example: Batman, when setting up his Team, might name it “Justice League”.
Now, it’s not acceptable to build a URL like:
example.com/team/Justice League
That’s not a proper URL. You could URL encode that string, but then you have ugly replacements. (All the %20 garbage, etc. And Batman hates the look of URL encoded strings.)
A better idea is this: When a user creates or updates the Team’s Name
, you also make a URL version and store that, too. (Perhaps on a field like Team’s URL Name
or similar.) My suggestion for this would be to create a URL Name that is either:
Team’s Name:search and replace (replace whitespace characters with nothing):lowercase
Or perhaps:
Team’s Name:search and replace (replace whitespace characters with ‘-’):lowercase
So that the Team URL Name (built from “Justice League”) becomes:
justiceleague
(in the former case) or justice-league
(in the latter case).
I could go on and on about nifty variations on all this, but it’s actually quite easy when you start thinking of this in terms of what’s really going on – we are, at the end of the day, just building a search type of page with an automagic search that happens on page load, where the search term comes from the URL path.