----- "Adam Young" <ayo...@redhat.com> wrote:
> > IPA class:
> > - IPA(path, type): Construct IPA object given a path to server's JSON-RPC or
> >                    static files.
> > - success(): Default success handler.
> > - error(): Default error handler.
> > - failure(): Default failure handler.
> > - execute(methodName, params, options, [success], [error], [failure]):
> >    Execute a method with optional handlers. The methodName should include
> >    the object name.

> > For the Web UI we could create a global IPA object that points to JSON-RPC
> > or sample data based on the current URL. The IPA object can be reused, each
> > entity only needs to invoke the execute() method and provides necessary
> > handlers.

This class could still be used in addition to your class below to provide
global settings for the entire application or test suite. For example we can
implement a default handler for insufficient access error.

> execute has a lot of parameters.  I think I would prefer a simple
>      execute(args, options,caller)
> It could then be called
>      cmd.execute(args, options,this)
> 
> The constructor can take a spec like this
>      var cmd =  command({entity: e, method:m, succes:s , error: e, 
> failure f});
> 
> and then we can check for the presence of each of the parameters.
> 
> The inline  case would be
>      command({entity: e, method:m, succes:s , error: e, failure 
> f}).execute(args, options);

I guess this class probably can be called IPACommand or something like
that. This class could be instantiated by invoking createCommand()
in the above IPA class. I'd ask though that the entity & method be
combined into a single parameter. This is just in case in the future
we will have a command that doesn't have an associated entity.

> caller would be an object that respects the contract
> {
>      on _error = function(){...}
>      on_success = function(){...}
>      on_failure= function(){...}
> }
> 
> With each of these functions being optional.  If set, they get called
> in place of the Command members.

I'm not sure about this, there's a potential of conflict if the caller
wants to use several different IPA commands.

> The prototype for command should have a default implementation for 
> error, success, and failure.  New instance should be created using a 
> clone, with the default as the prototype.

I'd rather override the default function with a custom one as needed.

So in the application initialization we could do this:
var ipa;
if (window.location.protocol == "file:") {
  ipa = new IPA("sampledata", IPA_JSON_FOLDER);
} else {
  ipa = new IPA("/ipa/json", IPA_JSON_RPC);
}
ipa.error = function() {
  if (insufficient access) {
    do something
  }
}

In the entity initialization we could do this:
var addCmd = ipa.createCommand("user-add");
addCmd.success = function() {...};
addCmd.error = function() {...};

In the button handler we could do this:
addCmd.execute(params, options);

Just my $.02. Thanks.

--
Endi S. Dewata

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to