Search form doesn't show entries
Closed this issue · 12 comments
Ok, so I removed all of my changes to test this, and sadly, I can't search for or select existing entries as they don't appear in the form.
I've checked the JS console, and nothing appears there.
I have a Types section which definitely has an entry whose name field is "Test Type". When I use the form and search for "Test" it tells me there are no entries. There's definitely something amiss here. Very happy to debug this Nils, where should I start?
Focusing the search form shoud trigger requesting the entries from the subsection. So do the entries show without typing anything? If not, have you selected the right subsection (sorry for asking :-))? Or maybe you have set a filter in the SSM field settings?
You could check what kind of request the JS does to fetch the entries. It should go to /symphony/extension/subsectionmanager/get/?id=foo§ion=bar
I'll have to look at that request, the form jumps a little as though an autocomplete box appears then disappears. I didn't think to check the DOM, so I'll do that now too.
Wow! Muppet strikes again!
I didn't completely remove my changes, as I forgot to remove the filter in the database.
Case closed. And my journey towards select box link filtering continues ;o)
And my journey towards select box link filtering continues ;o)
I hope you enjoy great landscapes, fantastic views and have a lot of fun ;)
Nils, I have been defeated. It's complicated for me to understand the subsectionmanager class properly. :(
It's complicated for me to understand the subsectionmanager class properly.
The thing is, it's complicated for me as well because a few things have been reworked by @ahwayakchih and I not sure I understand everything myself.
Ah, and by the way: there was a reason why we have been talking about creating a new relationship field in Cologne. All existing solution suck in their own areas. It's time to do it right, fixing the implementation of relationships in the core and allowing custom UIs that don't have to deal with the associations themselves.
That's because SSM tries to do too much. I think that it would be much simpler to specify "source" page (regular Symphony page, with data-sources, etc...) and simply get entries from there. Possibly with autocomplete, instead of pre-loading everything.
What's more is that the interface could be done with XSLT, so SSM would not depend on specific image module or JS, and developers could change the look of the list the same way they already work with Symphony's pages.
Hehe. I had exactly the same idea the other day. This way it would
even be possible to have multiple subsections simultaneously.
Am 05.07.2012 um 22:26 schrieb Marcin Konicki
reply@reply.github.com:
That's because SSM tries to do too much. I think that it would be much simpler to specify "source" page (regular Symphony page, with data-sources, etc...) and simply get entries from there. Possibly with autocomplete, instead of pre-loading everything.
What's more is that the interface could be done with XSLT, so SSM would not depend on specific image module or JS, and developers could change the look of the list the same way they already work with Symphony's pages.
Reply to this email directly or view it on GitHub:
#218 (comment)
This way it would even be possible to have multiple subsections simultaneously.
Exactly. Total freedom for developers :). Possibly with some default/example XSLT, building something similar to the current interface.
Field would just keep entry to entry connection. Nothing more. Unless i'm mistaken, entries have single ID table, so there will be no duplicated ID between two sections.
And connections wouldn't have to be unique (so, one could select some entries multiple times, e.g., multiple apples put into shop cart :).
Unless i'm mistaken, entries have single ID table, so there will be no duplicated ID between two sections.
Exactly. A subsection entry (displayed in the SSM) would implement a
default template, providing an @id attribute or similar at its top
level.
Am 05.07.2012 um 22:33 schrieb Marcin Konicki
reply@reply.github.com:
Unless i'm mistaken, entries have single ID table, so there will be no duplicated ID between two sections.
A subsection entry (displayed in the SSM) would implement a
default template, providing an @id attribute or similar at its top
level.
Yes. Probably as a hidden input.
There could be just a minimum "requirement" for source pages, like handling "search" (search for entries using text entered by user, and whatever data-source field filters are used in the setup :) and "id" parameters (to select entries by ID numbers). Maybe just ID, because search doesn't have to be implemented (it could be just a default/example implementation).