Item page from coded query

I need to achieve the following:

  • a logged in user with acces to a page should see a datatable with his current properties (a hotel, a restaurant, etc)
  • on clicking the Property Name cell in a grid, he would be shown a form with data to UPDATE (text, dates, pics). He cannot create new properties (INSERT, Addnew, etc)

I think it should be done this way (but not sure):
1: build a normal page with a datatable without a data connection
2: get his email address
3. build the query with eq(hisemail) [hisemail is a column in the dataset, set by admin]
4: build the column layout for table in code
5. map columns and resultset, display

What I do not get is how to mimic the standardized Items page (which you get for free if you add a dataset to your page), or, better yet, how do I pass the datasetId (the property clicked) to another page. Do I need to do that with an HTTP get and, in Items page, then parse the URL and retrieve the Item again?

Hey Giri,

I think I understand what you’re trying to do and the good news is that it should be much easier than you think.

For the index page you can use a dynamic category page that is setup via the URL to show the all properties of a single user. You can set the property name to link to the dynamic item page described below.

For the update item page you can use a dynamic item page with the dataset set to the Read & Write mode. Add a button to the page to save the edits to the item.

Now the trick is to send the user to the dynamic category page so that it shows only that user’s properties. You can do that by getting the current user’s info with the wix-users API, building the link to the dynamic page, and using the wix-location API.

Thank you very much, but I see a security risk in doing it like that. If you build a URL like …ItemPage/Id or even —ItemPage/User/Id, then another user, when logged in, could change that URL in the browser and access somebody else´s property, right?
A way to prevent this is that the ItemPage only recieves an Id and fetches this row with the UserId added, IN CODE, so not in URL.
Maybe I am missing something, it´s still a bit fuzzy to me.

You can write code on the page to check if the current user matches the one in the URL. If it doesn’t match, send the user to another page.

If that doesn’t meet your security concerns, then the way you first described will work as well. You can pass the ID of the property clicked using the wix-storage API and build the item page in the same way you describe the index page. Note that doing it this way means your users won’t have a unique URL for each of their items that they can bookmark, copy/paste, etc.

You also might want to look into doing this with router pages .

Sam, could you point me toward where I could learn more about how to write the code to make sure the current user matches the one in the URL?

It depends on what field you’re using in the URL. If it is the user’s ID or email address you can get that information from the wix-users API. If it is something else, you’ll probably have to do a query.

Really appreciate your help, you all bend over backwards to help us getting to grips with Wix Code. You have gold in your hands, it´s a very powerful tool. If you could just provide more documentation, maybe a thick book or something, with real projects and online code examples.
I believe it has been said before, but it looks like most users, me included, are simply not proficient enough in the concepts and syntax of server side Javascript in combination with the design decisions you had to make.
In my case, I understand perfectly what should be done, why it should be done this way and not that, but it is the physical coding that is the big hurdle. I have extensive experience with IIS, MS-SQL server and ASP-script, others might know a thing or two about PHP and MySql, but getting to grips with the new concepts of SS JS (why do we need to export functions inside our own code if no other app imports them …, (oh, wait, maybe there is …)), asynchronous functions and promises, it´s overwhelming.
We also lack insight in problems that we know from experience, but are not addressed, like Transaction Tracking (Commit, RollBack), especially when you are about to introduce Master/Detail structures.

In short: you have a jewel in your hands, but your audience couldn’t tell the difference between a diamond and a sapphire. You do not come from the coding community, you come from the Design-Your-Own-Beautiful-Webpage angle. And this audience needs help, a lot of help. You do your utmost best to offer this thru the forum and you sometimes write the whole function for us. That is of course appreciated, but if you could just provide us with good documentation, we wouldn´t have to bother you so much with our silly questions that make your eyes roll.

I, for now, will put the coding on halt, I simply don´t have the time to write a question for every line of code (after having searched thru all examples and API). I will try to contract somebody else. THat doesn´t mean I dump Wix Code, again, you are sitting on a pot of gold, but I will wait for the roadmap, preferably a 1000 pages long.
I sincerely congratulate you with the end result of your tremendous project.