This project is read-only.

Action not showing on Find menu

May 15, 2013 at 11:41 AM
Edited May 15, 2013 at 1:33 PM
I have a repository registered as a menu service with the following method on it.
    public SupplierBranch NewSupplierBranch(
        Region region,
        string name)
The above renders correctly, both in the top level menu, and on the Find menus

However, when I add the Supplier parameter, it no longer renders on the Find menus, although it renders and works correctly on the top level menus.
    public SupplierBranch NewSupplierBranch(
        Supplier supplier)
        Region region,
        string name)
Region is Bounded, Supplier is not.
Am I missing something?


NewSupplierBranch persists a new SupplierBranch instance, populating it off the incoming parameters, and returns that. I.e. not a transient instance.

I have verified that it is the Bounded vs. not Bounded entities.
I need to be able to create new instances of a parameter type of no such type exists, but for no-bounded entities.
Eg. in the example, if there is no existing SupplierBranch that is suitable, the user must be able to capture a new SupplierBranch on the fly linked to the Supplier (selectable via auto-complete).

Update 2:

Returning a transient instance of SupplierBranch could also be an option. I.e. if I let NewSupplierBranch take no parameters, but just return a transient, and then enter the field values and save.
However, once again this works fine off the top level menu, but not on the Find menu as a nested form.
The nested edit form for the transient does not render a Find menu for Supplier, which is required by SupplierBranch.
Having a frustrating time of this. Is what I'm trying to do not possible?
If not, it will severely hamper the user's workflow, as they well always have to first go and created a required entity through the top level menus, before being able to use that entity on another action.
Compounded by 2 or 3 levels of this.
May 15, 2013 at 3:03 PM
Edited May 15, 2013 at 3:06 PM
NOF will not recognise - as a Finder action - a method that takes a reference parameter other than a bounded type. The reason for this limitation - which was deliberately enforced - is rendering complexity. If you imagine that it did work, you would have this action appearing on the Find menu for an editable property (or a parameter in another dialog). If you clicked on NewSupplierBranch you would get a second level dialog opening up, requiring the parameters of that NewSupplierBranch method (a drop-down section of Region and a name, in your first case). But if any parameter is not-bounded (e.g. Supplier) then in order to provide the Supplier you will need a Find menu on that parameter, which would in turn open up a third level dialog - and so on. This would be horrendously complex to implement, but also very complex for the user to understand. The Find menu idea is complex enough as it is - since the introduction of auto-complete (recently) and of conditional-choices (longer ago) - my own view is to favour those as ways of completing dialogs rather than relying on the Find menu at all.

BTW, this is stated in the manual, thus:

"The Find menu will not include any action that would ordinarily include a Find menu on one of its parameters. This is to avoid ending up with a Find dialog inside a Find dialog - which would be potentially very confusing to a user, and very difficult to implement as an HTML form."
May 15, 2013 at 3:51 PM
The best way to work around this and preserve your workflow would be to go up a level. I assume that there is some object Foo (not specified in your example) that has a property of type SupplierBranch which has a Find menu, to which your working method is added. I'm guessing that Foo already has another property of type Supplier, which you allude to as having been looked up via auto-complete.

So, one work around is to have the SupplierBranch property to have a set of Choices based on the selected Supplier, plus one called CreateNewBranch

Underneath/alongside the SupplierBranch property you can have two new properties:
Region NewBranchRegion
string NeBranchName
These two properties can be marked up so that they only show up when Foo is transient. Then you can use co-validation to ensure that the user either has specified a real Branch OR has specified CreateNewBranch and has filled in the two properties - in which case on saving you can create the new Branch and associate it.

I'm sure there are some subtleties to this that need working through, but it is a possible direction.
May 15, 2013 at 5:11 PM
I'll investigate that approach.

I remember seeing something about actions rendering in modal dialogs in up-coming features. Would this not allow for multiple nested levels as per my need?
May 15, 2013 at 5:21 PM
"I remember seeing something about actions rendering in modal dialogs in up-coming features. Would this not allow for multiple nested levels as per my need?"

No. JQuery modal dialogs (which we are using for this) does not, I think, allow you to have multiple dialogs open at once - and even if it did, I don't personally think that multiple nested dialogs is a good idea, whichever way they were rendered - it's just too confusing for the user to follow.

Our new model dialogs can still have the nested in-line dialogs within them, as now. But as already said, in projects I am involved in I am encouraging moving away even from that.