Ticket #2529314 (closed enhancement)

Reporter


Luke Smith
Opened: 09/14/10
Last modified: 08/18/11
Status: closed
Type: enhancement
Resolution: fixed

Owner


Thomas S. Sha
Target Release: 3.4.0
Priority: P3 (normal)
Summary: Instantiable IO
Description:

This may be a duplicate, but I think it would be convenient to have Y.io be a convenience method over the top of an instance based architecture.

So something like
Y.io = function (url, config) {
var instance = new Y.IO({ ...stuff based on input... });
return instance.send.apply(instance, Y.Array(arguments, 2, true)); // send extra args or possibly pull from config.args
};

also allowing

var server = new Y.IO({ config });
server.send(stuff);
server.send(other stuff);

and/or
server.send(stuff, successCallback);

I believe gallery-resource aims at creating this model.

Another opportunity here is to have the IO class and API be a base class with no transport implementation, then implement XHR, or XDR, or other transport forms as extension classes or plugins. That
would allow implementers to include only the API and particular transport implementation that was right for their needs. Maybe this should be a separate ticket.

Type: enhancement Observed in Version: 3.2.0
Component: IO Severity: S3 (normal)
Assigned To: Thomas S. Sha Target Release: 3.4.0
Location: Library Code Priority: P3 (normal)
Tags: Relates To:
Browsers: N/A
URL:
Test Information:

Change History

Adam Moore

YUI Contributor

  • Username: adam
  • GitHub: apm
Posted: 09/14/10
  • blocks changed to 2529318

Eric Ferraiuolo

YUI Developer

  • Username: ericf
  • GitHub: ericf
Posted: 09/15/10
  • blocks changed from 2529318

As Luke mentioned I took this approach with my Resource Gallery module: http://yuilibrary.com/gallery/show/resource

Y.Resource is about creating a RESTful HTTP client API.

Luke where you talk about var server = new Y.IO({ config }); I think the right breakdown is at the HTTP Resource level; this is what I did in Y.Resource. So when creating a new Y.Resource({ config }) you're configuring the object to match-up with the server-side HTTP Resource it's communicating with.

Another benefit with the instance-based approach is the ability to create an instance and pass it around to other objects which could make method calls on it. I've used this approach often with Y.Resource, creating instances and passing them to Widgets (as attribute values); this way the Widget doesn't have to be configured with all the details of the IO config.

Luke Smith

YUI Contributor

  • Username: lsmith
  • GitHub: lsmith
Posted: 09/15/10

If by HTTP resource, you mean a specific web service, then yeah.

The breakdown needs to be fleshed out between what is configured per instance and what is passed as arguments to send() (or whatever that method would be), including transaction-specific configuration/overrides. I can see instance configuration being defaults for generated transactions, and maybe a sig like send(data, configOverrides) for per-transaction configs (similar to what you have in Resource).

Luke Smith

YUI Contributor

  • Username: lsmith
  • GitHub: lsmith
Posted: 09/18/10

Async form support seems like another opportunity for an instantiable class. But maybe that would be better represented as plugin to a Form class.

Thomas S. Sha

YUI Contributor

  • Username: tsha
Posted: 09/18/10
  • status changed from new to accepted

To preserve backward compatibility, IO would have to know when it is being called as a static constructor (current operation) and when it is being called as an instance constructor.

The compatibility step is quite important, as implementing instantiable IO will break the synchronous request model (and, abort and isInProgress methods for asynchronous requests), unless instantiable IO was facilitated through another, new constructor.

Thomas S. Sha

YUI Contributor

  • Username: tsha
Posted: 10/12/10
  • milestone changed to 3.NEXT

George

YUI Developer

  • Username: george
Posted: 04/29/11
  • milestone changed from 3.NEXT to 3.4.0 PR1

George

YUI Developer

  • Username: george
Posted: 05/15/11
  • milestone changed from 3.4.0 PR1 to 3.4.0

George

YUI Developer

  • Username: george
Posted: 05/15/11
  • completed changed from 0 to .5
  • estimated changed from 0 to 1
  • remaining changed from 0 to 1
  • sprint changed to 3.4.0 PR1

George

YUI Developer

  • Username: george
Posted: 06/8/11
  • sprint changed from 3.4.0 PR1 to sprint 1

Thomas S. Sha

YUI Contributor

  • Username: tsha
Posted: 06/22/11
  • completed changed from 0.5 to 2
  • remaining changed from 1 to 0
  • status changed from accepted to checkedin

George

YUI Developer

  • Username: george
Posted: 08/18/11
  • resolution changed to fixed
  • status changed from checkedin to closed