Dynamic Adds with Save(apply) functionality #194

New Issue

Closed

opened 2017-12-07 12:18:54 +00:00 by wxkeep · 7 comments

wxkeep commented

2017-12-07 12:18:54 +00:00

(Migrated from github.com)

Steps to reproduce the issue

Linked views in admin view with the "add new button" checked. When the "new" button is used, the follow-up screen only offers "save & close" and "cancel."

Expected result

Would be great to see other buttons (or the ability to customize the buttons) such as "save(apply)" and "save and new"

### Steps to reproduce the issue Linked views in admin view with the "add new button" checked. When the "new" button is used, the follow-up screen only offers "save & close" and "cancel." ### Expected result Would be great to see other buttons (or the ability to customize the buttons) such as "save(apply)" and "save and new"

Llewellyn commented

2017-12-07 16:16:10 +00:00

Delete? can you please give me a screen shot so I understand what you mean. Delete does not make sense to me at this time.

wxkeep commented

2017-12-07 16:43:21 +00:00

(Migrated from github.com)

My apologies. It was very early in the morning. =)
I have updated the original request.

My apologies. It was very early in the morning. =) I have updated the original request.

Llewellyn commented

2017-12-07 16:56:42 +00:00

Okay we can not do (save & new) there are just to many complications, since some areas can not have more then one item per ID, but we can look at the option for save(apply) that will save the changes but reload the page instead of closing it.

You know the real reason behind this is the return value, to take you back to the page of origin when you close or save and close.

I would still like that screen shot to make sure we are on the same page.

Okay we _**can not do**_ (**save & new**) there are just to many complications, since some areas can not have more then one item per ID, but we can look at the option for **save(apply)** that will save the changes but reload the page instead of closing it. You know the real reason behind this is the return value, to take you back to the page of origin when you close or save and close. I would still like that screen shot to make sure we are on the same page.

wxkeep commented

2017-12-07 17:35:16 +00:00

(Migrated from github.com)

Ah. That makes sense. What I'm attempting to do is have multiple linked views, however.

[profiles] is linked to [dimensions] and [dimensions] are linked to [explanations]. Under the current practice, I have to save and close the dimension and the go back into the dimension to add the explanations. Granted, all can be done from the master views, but I'm trying to streamline the user experience.

Ah. That makes sense. What I'm attempting to do is have multiple linked views, however. [profiles] is linked to [dimensions] and [dimensions] are linked to [explanations]. Under the current practice, I have to save and close the dimension and the go back into the dimension to add the explanations. Granted, all can be done from the master views, but I'm trying to streamline the user experience. ![image](https://user-images.githubusercontent.com/34340812/33729220-96782344-db42-11e7-9319-e27bce871eb6.png) ![image](https://user-images.githubusercontent.com/34340812/33729236-a234ef82-db42-11e7-8515-87cf8e58f2a9.png)

Llewellyn commented

2017-12-07 20:55:57 +00:00

This is what makes it hard to navigate the next step. So I have tried to achieve this kind of dynamic behavior with the new Joomla Component view and its relationships with the linked views. But as you will see I linked it in via Ajax and lots of custom JavaScript on the page.

So we on purpose remove those buttons when we detect that the view is opened and has a refid (int) or/and ref (string) just check the URL. Since this indicates that the view was opened from with in another view and that we should return to that view when done here. When you do save & new the controller drops the refid (int) or/and ref (string) and we no longer know where to return to (ahh). This is the reason we hide the buttons so that one event/click will always result in taking us back to the view of origin. Since the view of origin is checked out and if we do not return an close it, it will remain checked out. That is what I thought it would be the most expected behavior to always go back. But I have since then seen that this is not always what I want to happen. Yet I have not yet come up with a stable alternative.

I am wondering what about two buttons:
[new] [close & new]

The first new will then do as it does now, the second will close out of the current view and basicly be like creating a new from the master views as you called it. This will then have all the buttons in view and at the same time check the view of origin back in, meaning that it will not be needed to go back and close that view as to check it back in, it will do all that within the new button [close & new]

What do you think?

I am wondering if we should add a switch that allows you to chose the behavior. You see the issue we have here is that of multi inheritance of the return/origin values. You see creating a new dimension does not naturally link it to the correct profile of origin. This is what makes it hard to navigate the next step. So I have tried to achieve this kind of dynamic behavior with the new Joomla Component view and its relationships with the linked views. But as you will see I linked it in via Ajax and lots of custom JavaScript on the page. So we on purpose remove those buttons when we detect that the view is opened and has a **refid** (int) or/and **ref** (string) _just check the URL_. Since this indicates that the view was opened from with in another view and that we should return to that view when done here. When you do **save & new** the controller drops the **refid** (int) or/and **ref** (string) and we no longer know where to return to (ahh). This is the reason we hide the buttons so that one event/click will always result in taking us back to the view of origin. **Since the view of origin is checked out and if we do not return an close it, it will remain checked out.** That is what I thought it would be the most expected behavior to always go back. But I have since then seen that this is not always what I want to happen. Yet I have not yet come up with a stable alternative. I am wondering what about two buttons: [new] [close & new] The first new will then do as it does now, the second will close out of the current view and basicly be like creating a new from the **master views** as you called it. This will then have all the buttons in view and at the same time check the view of origin back in, meaning that it will not be needed to go back and close that view as to check it back in, it will do all that within the new button **[close & new]** What do you think?

Llewellyn commented

2017-12-07 21:02:57 +00:00

Sorry I know this may all sounds a little crazy... hmmm but I hope you could follow the reason here. It just because of the checkout of item that I need go back, and yet that going back was and still is nice so you can make a change to a linked concept and yet go back to the main concept and continue working on it. That is the current behavior.

So I am proposing a new switch in JCB when you setup the linked view, and this switch will add or not add the new button called [close & new]

Sorry I know this may all sounds a little crazy... hmmm but I hope you could follow the reason here. It just because of the **checkout of item** that I need go back, and yet that going back _was and still is_ nice so you can make a change to a linked concept and yet go back to the main concept and continue working on it. That is the current behavior. So I am proposing a new switch in JCB when you setup the linked view, and this switch **will add or not add** the new button called [close & new]

wxkeep commented

2017-12-11 16:20:58 +00:00

(Migrated from github.com)

I like that idea. I think it gives flexibility.
I see the struggle with maintaining the main refid and, ultimately, returning to the main profile. I hadn't considered that. I think your switch idea sounds like a great compromise. =)

I like that idea. I think it gives flexibility. I see the struggle with maintaining the main refid and, ultimately, returning to the main profile. I hadn't considered that. I think your switch idea sounds like a great compromise. =)