User Navigation Design Pattern

[delphi'sghost]

I have an edit page for a widget, and each widget has a set of sub widgets. I want to show the widget details as editable inputTexts, and have a clickable list of subwidgets. If you click on a subwidget, you go to a page to edit the subwidget, click save on the subwidget page, and it should save the subwidget, and take you back to the widget edit page. On the widget edit page, you can finish editing the widget, click save, and it will save the widget.

I'm finding this hard to do in seam, since the entity manager flush mode is set to manual, and obviously, when I flush it for the subwidget, it also flushes it for the widget itself which I don't want.

I'm wondering whether a) I can do this in seam, or b) I'm still thinking in desktop client/server mode and need to adapt my ideas of user interaction to adapt to the web, for which seam is most suited.

Regarding option A, I'm wondering whether I need to do something along the lines of starting a nested conversation, and trying to get a new entity manager. I have tried to put the subwidget editor into a separate nested conversation, but it appears not to work since it shares the entity manager (I'm using the @In EntityManager entityManager seam managed transactional entity manager).

For option B, I can see that my current problem is that I am trying to have 2 different 'editors' in the same conversation space, and I can't pick and choose which one I want to flush. This leads me to think my interface design is wrong. We are inexperienced web developers and still thinking in client/server mode.

As an alternative navigation/interface design, I'm thinking of a 'view widget' page which lets you see the details as view only, with a link to edit the details. The view only page also has the clickable list of subwidgets which takes you to a page to edit the subwidget. The navigation would then revolve around the view details page, and you can only edit one item (widget or subwidget) at a time and go back to the view details page each time after saving the item. With this design, I don't think I will have any problems implementing it in Seam. This also gives me the benefit of having a page with view only access that the user cannot edit, and I can check rights to see if they can edit the widget/subwidgets. I also notice that this is similar to the style that seam-gen uses when it generates the crud pages.

Anyone's experience or thoughts on this would be most welcome.

[hstang]

Hi,

Just wondering what your thoughts are using two independent conversations for editing the edit widget and their children widgets

[delphi'sghost]

Hey,

I had considered that, and part of my reluctance is the messyness involved in keeping a new subwidget informed of it's widget and vice versa. The subwidget has a property called Widget which refers to the owning widget. The Widget has a property called getSubWidgets which returns the list of subwidgets.

The edit widget page is in a long running conversation, so I think the only way to start a separate conversation is by issuing a GET request and not use any conversation propagation, starting a new conversation using a link such as /editSubWidget?subWidgetId=123. You don't need to pass any parent widget information since you are editing an existing subWidget, and it already has a parent Widget.

However, when you want to create a new subWidget, say by not sending in the subWidgetId, then you do need to provide a widgetId to indicate which widget is the parent, and you need to load that widget and use it with the new subWidget.

By keeping everything in the same conversation, I can just reference the bijected widget variable to get the widget I am currently working on and will be the parent of my new subWidget.

Additionally, if I create a new subWidget in a separate conversation, I then have to find a way to notify the original Widget instance that it has a new child. I could start getting into seam event handlers to do that but again, it starts getting messy.

Neither are overly complex, but we are aiming to keep things simple due to really tight deadlines, and our inexperience with web development and seam.

To add to the problems, we are trying to do it all using pageflows since the editing process can have multiple steps, which complicates matters as far as nested conversations go.

I don't know, maybe we're looking for too simple a solution, does everyone else go through these kinds of hurdles in order to deliver web sites with seemingly logical editing navigation?

[delphi'sghost]

I started to have another look at the Issues example application that comes with Seam since it has a lot of nested conversations as you drill down from project to issue etc.. kind of similar to what I'm looking for.

Looks like it has problems also. If you change the project name, click done (no update) it refreshes the project and reverts back to its original name. However, if you change the project name, and then edit an issue, and save the issue, when you go back to the project page and click done, it does not roll back the change even though you never saved the project change.

The same also applies if you repeat the process with the Issue and a comment. You can't save the comment without forcing updates to the Issue.

However, it does not use the manual flushmode, so that would explain why the objects are updated when they shouldn't be, so I guess this is just a bug in the issues application. It would be interesting to see how the Issues app would get around the problem of drilling down without forcing everything in the parent conversations to be saved.

[pmuir]

The issues example has been removed from Seam as of 1.3ALPHA.