[Cosmo-dev] Cosmo WebUI Service Layer
br at osafoundation.org
Mon Mar 5 13:30:57 PST 2007
Overall seems pretty good. Here are my comments:
> "Therefore, there should be a single Conduit instance for
> interacting with a user's "Owned" collections, and a single Conduit
> instance for each ticket in a user's subcriptions."
I think it's more accurate to say "...a single Conduit for each of a
user's subscriptions" - which would probably be the same as one for
> Example: retry
> There will, in the future...
I would also like to see a way for the owner conduit and subscription
conduit (and all other conduits which require login) to prompt the
user to re-login if they've timed out and then automatically retry
> Please see the dojo.Deferred API reference for more information
> about Deferreds.
Doesn't really tell you that much unfortunately...
> Model Data Convenience Syntax
Looks ok, but still worried about this for some reason.
Why does the collection object have a getItem()? Items don't belong
to a particular collection and you can identify them solely with the
> The Conduit API will be stable enough for business object use.
> However, it is recommended that developers use the Model Data
> Convenience affordances whenever possible.:
I'm thinking we should insist that other code only use the MDC stuff.
The MDC api is likely to be more stable, and I'd rather not have to
make the UI dev manually inject conduits into newly created items/
why not "delete()"?
Also, what do we do about "new" items? Does the conduit become like
an item factory - "var item = conduit.newItem()" ?
For MDC we could do "var item = collection.newItem()"
But then how do you get a new collection?
Also, how does the one (if one can) get a handle on the list of
conduits that are "loaded"?
More information about the cosmo-dev