Problem with buttons on 1:4:4 table layout

A long time ago, when the old forum existed, I had a problem.
Well, I still have it.
For those sufficiently bored enough here is the original thread.
http://www.typolight.org/forum/topic/7410.html?page=1

This is the problem as I outlined it

Quote:

---

hi all, i have 3 tables (tl_subject,tl_playlist and tl_playlistitem) representing three levels ...parent, child and child's child.
When i edit a playlistitem the "Go back" link returns me to the subject (first level) rather than the playlist (second level).
The link has an href of "do=ModuleName".
I assume it needs to say "do=ModuleName&table=tl_playlist"

Where can i change this to refer back to the middle table (list)?

---

The last post I quote here, then the forum was closed and we switched to this one.

Quote:

---

I add a subject(parent table),then add a playlist(middle table).
If i edit the playlist header, I have a save and new button present.
Using this button does not work (it seems to operate - i can fill in the fields, but it does not add a new playlist to the database at all).
I can't see a DCA solution to remove this.

So to recap, i still have two problems....
I need to remove this saveNcreate button, and also remove the backBT goback button.(or change their behaviour)
Leo, is this even possible?

---

I have added in a button that returns the screen to the playlist, but I still need to remove somehow these 2 extra system generated buttons.
Andreas thought it was a bug, Leo thought he'd corrected it, but I still have the problem.
Vultur suggested a patch to DC_Table below, but it just makes things mis-redirect in other ways.

Code:

---


//WITHIN        protected function parentView()

                $return = '
 <div id="tl_buttons">

//DELETE THIS:
'.$GLOBALS['TL_LANG']['MSC']['backBT'].'' . (($this->Input->get('act') != 'select') ? ' &#160; :: &#160; ' . (!$GLOBALS['TL_DCA'][$this->strTable]['config']['closed'] ? '

//ADD THIS INSTEAD:
'.$GLOBALS['TL_LANG']['MSC']['backBT'].'' . (($this->Input->get('act') != 'select') ? ' &#160; :: &#160; ' . (!$GLOBALS['TL_DCA'][$this->strTable]['config']['closed'] ? '


 strTable]['new'][1]).'" accesskey="n" onclick="Backend.getScrollOffset();">'.$GLOBALS['TL_LANG'][$this->strTable]['new'][0].'' : '') . $this->generateGlobalButtons(). ($blnClipboard ? '  ::  '.$GLOBALS['TL_LANG']['MSC']['clearClipboard'].'' : '') : '') . '
 </div>';

---

Leo, should I submit this as a bug? I'm not really sure if its me or typolight.

Any/all thoughts appreciated.

Ramjet... Since TL doesn't really allow this 3-level situation, as the DC_Table hasn't been coded to work with more than one ID=xxx value and a table, how did you ever get this working. I have the same situation now.

Calendars => Events => Bookings
but now I can't get bookings to be listed below events... I had to make it a root level BE app to get it to work. I also couldn't make it tiered off another table (to filter for 1 event), as parent tree views MUST be nesting (pid's pointing to its own ids). I'd like a tree view that supports a flat structure...

Hiya Thyon.

Quote:

---

how did you ever get this working?

---

The correct buttons you mean? I never did.
I managed to genenerate another button to compensate, but never could get rid of the system generated one.

Heres a skeleton of the architecture I use for parent/child/child if its any use to you
(just install) but as you'll see middle table go backs misfire.

I know why it never works... because your link to the child->child table is always assumed to be a root parent-child table. You cannot have a 3-level at all.... you're only ever editing 1 table, appearing under a parent somehow... Even Article-CE is 2 levels with pages only displayed for info (you can't edit them directly/normally, unless you add buttons to another parent editing view, site structure).

Quote:

---

You cannot have a 3-level at all

---

Thats funny, I've got several modules made that operate that way. :D The buttons are the only problem, and its only a minor really. I can create a functioning one, I just can't figure out how to get the wrong one to go away.

I meant, you're faking it, by replacing the stuff that leo assumes to be 2-level by default and "making" it look like 3-level...
basically, you're intercepting all the functions in the 3rd level and 2nd level to make it look like 3-level. You can remove the edit/cut/delete buttons yourself from the DCA... but the back-link is hard-coded. There isn't one to remove the go-back though, as its always assumes that you're going back to the table itself, or its parent, never deeper.

Come one ramjet... write us a n-level DC_TableSet.php

Did you install my module (attached 4 posts up)?
Either we're talking cross purposes or this is a demo of it. (it uses 3 tables-doesn't that mean its 3 level??)
I've never faked it in my life... honest :lol: (i don't know why that jar of mayonaise is by my bed!)

If Tl supported n levels, Leo would have made a single interface to edit pages, articles and content, yet he spilts each 2-level. It seems there isn't a single working module that uses 3+ levels. Maybe TL's only for up to 2 years old?

Ps. I did install it.

Quote:

---

Ps. I did install it.

---

So to you this is a "faked" 3 level architecture? I don't quite get what you mean by that but it doesn't matter, as it works well for my purposes (ie storing and managing info 3 deep) .

I take it you're saying my button problem can only be solved at Table driver level by adapting DC_Table and using this adapted driver?
That was more-or-less vulturs original suggestion too, although he suggested modifying DC_Table which I was against because of upgrade problems. I wasn't aware of the concept of writing a new one.

Cheers for the pointers Thyon. I'll have a bit of a nosy in the Table Driver then.

Leo, when you get a bit of spare time (if you ever get a bit of spare time) I'd love to hear your comments on this.

Hi ramjet, thyon,

I installed your test144 extension and can confirm, that the back button from within list items misbehaves and jumps back to subjects instead of lists.

However I'm pretty sure, that TL supports 3 (or more) level table designs. Look e.g. at the extension [survey_ce] and it's database diagram. From the diagram you see tl_survey ---1:N--< tl_survey_page ---1:N--< tl_survey_question. Install the extension and try it in the backend. You'll see, that the back button from the list of questions correctly shows the page list. I did not try to find out, why it works in [survey_ce] but not in yours (lack of time) ... thus I must leave that as an exercise to you :D ... but I would be interested in your findings!

best regards, Georg

Thanks for the pointer Georg,
I'll definitely have a look at that, but not for a few days unfortunately as I'm pretty snowed under at the mo... cheers very much, murray.

Yeah, his is the same layout, but somehow the back link points in all cases to "?do=survey" so I have no idea how it then recognises itself as being part of a 3-table, and then when clicking on the link in the questions table (to go back to the page), then it goes back to the page table list, instead of the survey listing.... Hmmm... Helmut, how did you do it?

Could you post datamodel.png here if you can access it (i can't i think because I'm not a german forum member)...

Hi ramjet,

here is the datamodel.png.

Best regards

He's intercepting and redirecting the go back button.
If the back button is clicked on from the grandchild it goes to the grandparent (my problem exactly) , but he tests the referrer in the first level (tl survey) - and if the referer is third level (tl_survey question) he kicks it to the second level (tl_survey_page) using $this->redirect.

The code is at the bottom of dca/tl_survey.php

Code:

---

class tl_survey extends Backend
{
        /**
        * Load database object
        */
        protected function __construct()
        {
                parent::__construct();
               
                // somehow dirty patch to allow going back if someone clicks back on a survey question list
                if (strpos($this->getReferer(ENCODE_AMPERSANDS), 'tl_survey_question'))
                {
                        if (preg_match("/id=(\\d+)/", $this->getReferer(ENCODE_AMPERSANDS), $matches))
                        {
                                $page_id = $matches[1];
                                $survey_id = $this->Database->prepare("SELECT pid FROM tl_survey_page WHERE id=?")
                                        ->execute($page_id)
                                        ->fetchEach('pid');
                                if ($survey_id[0] > 0)
                                {
                                        $this->redirect($this->addToUrl('table=tl_survey_page&id=' . $survey_id[0]));
                                }
                        }
                }
        }

---

I could create a new goback button that went to the right place, but couldn't get rid of the old one.... whereas Helmut just tests the old one when it lands and redirects it. Clever clever.

Thank you Georg. Thankyou Thyon. Thank you Helmut. Thats my solution.

finally, now you understand by what I meant by faking it.... leo didn't design it that way, but helmut found a clever way around it... PS. this only works on a "4" structure, all other types generate an error in TL.

Good morning (here in Germany :-) ) ramjet, thyon,

@ramjet: many thanks for your analysis and publishing your findings
@helmut: wow, i DID see that comment "// somehow dirty ...", but never got around to understand, what you tried to achieve
@thyon: seems, you are so right

Being a newbie with TL, what should we do with this situation? Just accept and use Helmuts clever workaround?

Or try to get that working by default in TL? I think, 1:N:M is a common situation (at least with sort modes 1:4:4). Thyon, you seem to have the best understanding of the DC_Table implementation, do you see any chance, especially a simple one?

As far as I can see DC_table IS prepared for 1:N:M, when e.g. deleting the master parent entry from the DB (recursively deleting all child and grandchild records). When duplicating the master record (in [survey_ce]) however, I had to recognize, that MOST of the children and grandchildren were duplicated, but SOME child records (survey pages) were MISSING, often just one (and then the grandchildren didn't exist in the DB too). Again the "middle" table was affected, in essence.

I think, there is some bug lurking, but I couldn't spot it yet, only it's (MISSING) "let behind". And I have a workaround (dup the original survey again, most of the time ANOTHER page is missing, then copy the the missing page from the 2nd copy over to the 1st copy and you are fine. Don't forget to delete the 2nd helper copy).

This might be as well a bug in [survey_ce] ... but I don't think so, because Helmut has NO active code at all for the deep cloning (unless I again missed some special handling in dca or so).

best regards, Georg