Uploaded image for project: 'SwitchYard'
  1. SwitchYard
  2. SWITCHYARD-619

Need a convention for plugin "create" methods and optional parameters

    Details

    • Type: Task
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 0.4
    • Fix Version/s: None
    • Component/s: tooling
    • Labels:
      None

      Description

      BPMServicePlugin.java has a create method with 7 parameters - many of which are optional. Many of our other plugins have a similar situation - the ClojurePlugin's create has 6 parameters, and the RulesServicePlugin's create has 3 optional parameters as well.

      Need a strategy for dealing with this - should the optional parameters be pulled out and put into their own separate modifyX methods?

      from Keith from irc :
      12:37:57 PM) kcbabo: tcunning: I'm not sure, there are a couple of options with separate pros and cons
      (12:38:10 PM) kcbabo: tcunning: one thing with forge is that you can "cd" into a resource, IIRC
      (12:38:20 PM) kcbabo: tcunning: which gives you context-senstive command access
      (12:38:42 PM) kcbabo: tcunning: so you could CD into a service component (for example) and have localized commands to modify stuff
      (12:38:57 PM) kcbabo: tcunning: another option is to simply add more commands that can be used to modify stuff
      (12:39:10 PM) kcbabo: tcunning: the drawback there is that you could end up with loads of commands
      (12:39:27 PM) kcbabo: tcunning: I think a JIRA is a good idea - not sure we'll reach agreement in time for 0.4, but you never know

        Gliffy Diagrams

          Attachments

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                tcunning Thomas Cunningham
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated: